This is a major fault. If you do not have the option of using one of the individual flavors of Revit 2013 original image and have to rely on the BDSP I feel really sorry for you. What we did in 2012 was extract the original image of RAC2012 to a local drive and then place that data on a DFSR hub server so it could replicate to all of the offices branch servers where we needed to create installations. You could probably do something similar, cherry picking the Revit2013 folder from C:/AUTODESK after you have waited three hours for the BDSP image to extract to your local drive ;-)
Autodesk gave us BDSU as a deployment tool only so we could get Revit oneBox and I never could get it to create a deployment. I ended up using the free download of Revit to create the deployment :-P
If you are using Revit Server, this is a good method to place the rsn.ini file in the correct location for your Revit client install. See more here:
The deployment did not modify the share permissions. I had the share permissions set up correctly prior to running the deployment. In fact the person who performed the install was using an admin account and the client and server are not just on the same domain and workgroup they are in the same physical location. The same error shows up in the revitcustom.log as described by others in this post
Have there been any accomodations made in the deployment tools to be able to install the RSN.ini file? This is going to be something of a pain to manage and keep updated. The reality is that a server may be added and removed at various times. The method of deployment presented here is very idealized. Has thought been given to how large firms will manage this?
What the what? On the last item '... if the user was not recently working in the particular model at all, then the lock may have been generated because the model is linked into another...'
Robert, are you saying that a model can become locked by an event that occurs in another model that it is linked into? We have run into some weird stuff but not this one!
Thanks for your response. I am looking forward to seeing the article to be posted to WikiHelp in the near future. I don't see any suggestion to use the Revit Server Admin Console to place an intentional lock on the problematic model prior to deleting the .lock file(s). I feel like I may have tried this in the past but it did not work. Can you confirm the procedure and supplement with the recommended use of the Revit Server Admin Console and/or the Server based command line lock utility?
On the item 'How do I clear user locks if the network becomes unresponsive or a server-based transaction is interrupted?'
Should both the 'Data_Users.lock' and the 'Permissions_Users.lock' file be removed? The prescribed method up until now has been to clear the contents of the Data_Users.lock file and leave the Permissions_Users.lock file alone. It seems that removing the contents of the Permissions_Users.lock file can render users local copies useless.
Question from Jason Bailly: should both the 'Data_Users.lock' and the 'Permissions_Users.lock' file be removed? The prescribed method up until now has been to clear the contents of the Data_Users.lock file and leave the Permissions_Users.lock file alone. It seems that removing the contents of the Permissions_Users.lock file can render users local copies useless. Is the new direction above coming from the Revit Server development team? It's hard to tell who is writing the policy on these WikiHelp entries.