The nature of deployments means that they will most likely end up on a network server somewhere. But for one reason or another, you might not want to just dive in and create those deployments right on the server: you could be running out of space, you might be testing out a new configuration, or it’s often just a good idea to test these things out first anyway.
Two assumptions with this trick. First, you are using the Autodesk Deployment tools with your software. Secondly, you are going to be deploying from a mapped drive (that has its own potential issues, but it’s a very common practice).
I like to be able to have my cake and eat it too. In this case, that means creating a test deployment in a sandbox, but being able to use it for my final deployment if it works. Let’s say we want to make our deployments on the network L: drive. Being good software folks, we don’t want to create our deployments on that drive directly. It’s easy to disconnect the drive, but how do you convince your local PC that it has that L: drive?
Time to crack open the Command Line! Good old DOS. The command subst allows you to set a local folder as a new drive letter, spoofing it so Windows sees a new drive.
I’ve used this all the time to build deployments. I have to make sure my folder tree matches the real network drive… so if my network deployments live under L:\Autodesk, I make a folder on my C: drive called Deploy, then I use subst to make my computer think that C:\Deploy is L: and then I just need to create an Autodesk folder under C:\Deploy.
So I create my Autodesk deployments, say the administrative image path is L:\Autodesk\<<whatever>>, and I am creating test deployments on my hard drive, that I can then just move up to the network location if they work. All the paths will align properly and users can then run the install from that L:\Autodesk path.