Seven Songs about Scripts and How They Improve a CAD Manager’s World
The first CD I ever purchased with my allowance money was the debut studio album by the Spice Girls. I remember playing it over and over on my boom box as I rode my bike around in a circle on the driveway. I soon acquired more CDs, and it eventually became a big issue for me as an eight year old to hop off my bike to manually change the CD when it was done playing.
Then one day, I discovered my dad had acquired a five-disc CD changer and my world was transformed. Everything was easier and more automated. I didn’t have to take extra time to manually change the CD. I had a process that did the work for me, and I was able to go on with my day.
What does all this mean? It means that a very simple script is a lot like the five-disc CD changer in the story (except way more powerful). This article will show how simple scripts can help CAD managers reach their automation goals in a carefully selected playlist of Seven Songs about Scripts.
1.“What’s a Script? (Baby Don’t Hurt Me)”
The first song on the list asks the most important question. What exactly is a script? A script is a powerful tool that can be used to automate tasks for the aspiring CAD manager. The tasks can include copying and pasting files, overwriting files, backing up files, naming files, and more. Regardless of which Autodesk® product you are using, there can potentially be a lot of customization files to manage. For AutoCAD® MEP, having a custom CUIx file, custom Content Builder content, user profile, various automation files, tool palettes, etc. can yield more than 1,500 files to deploy. (I would know… I counted!)
Manually deploying all these files can lead to mistakes, not enough files being accounted for, and countless hours troubleshooting why your sweet custom setup just does not work on the end user’s computer as well. You can write a script to automate the task of copying in files where they are supposed to go, so you don’t have to do it manually. No fancy programs are required. You can simply use Microsoft® Notepad® (or Notepad++ if you have it) to create a simple script.
It is important to note that scripts are powerful and that is not something to be taken lightly. Incorrectly using scripts can potentially overwrite files you didn’t intend to overwrite, and that will hurt. In this article, I will describe the approach I take to writing scripts. However, I highly recommend certain safety measures if you are new to the concept. In other words, don’t try this at home unless you incorporate the following steps.
Save scripts created in Notepad as text files (.txt) until you are ready to test. (Save as .cmd or .bat later.)
Right click>Edit to edit any script that does not have .txt as a file extension. Simply clicking on a script file can run it!
Set up local test folders so you can see what is happening when you run your scripts before you configure them to be the file paths you actually need them to be. This is the most important tip because syntax matters!
2.“Deploy Me Maybe”
The next song on the list addresses how to use scripts to create a local deployment assembly pack, which is basically an assembly of all the files that will eventually be distributed. To do this, simply open up Notepad to make use of the following concepts shown in Figure 1.
Figure 1: Concept
Figure 1 shows three different ways to use Robocopy (or robust copy) to copy files from the source file path to the destination file path.
Copy all contents of the source file path and put them in the destination file path.
Copy one specific file from the source file path to the destination file path.
Copy any files that have part of a file name from the source file path to the destination file path (this comes in handy if you don’t want to spell out several specific files).
Creating a deployment assembly pack may sound redundant, but being in a CAD management role means I’m testing things all the time. I don’t want to accidentally include test files or future development files while deploying content to others, so I make all my files copy into a nicely formatted deployment pack with subdirectories that house many different custom files. This deployment assembly pack acts as a final checkpoint before everything is sent to the server. This is important because once your files hit the server, they are considered “live” and ready for end users to retrieve. See Figure 2 for a simplified script on assembling a deployment pack for AutoCAD® MEP.
Figure 2: Deployment assembly script
Notice there are a few additions to the main concepts shown earlier.
REM to allow for embedded comments/notes that help with troubleshooting and ensuring everything is accounted for
Options or switches like /e and /mir to tell the scripts to copy in all subdirectories and make the destination files look exactly how the source files look (mirror/overwrite if necessary)
“Version” of the deployment pack, which is just a simple text file with the date and details of the update noted within it (Figure 3)
Figure 3: Deployment version
Following this script example will create a nicely formatted deployment assembly pack that pulls files from wherever you have them on your local machine. This deployment assembly pack will allow you to verify its contents in a well-organized way before it is sent to the server. Treat this script as something that is nice and beneficial to have, but not required. I mainly did this because I had reasons to keep many of the out-of-box AutoCAD file paths for my custom files to also reside.
3.“Send the Files Up Before you Go-Go”
Making hundreds of files available on the server makes it easier for rolling out deployment packs (read: your company standards), because any other method of distributing those same files could be very cumbersome. It is important to house these files on the server (for distributing purposes) because something could always happen to individual computers and local files where your customizations should ultimately reside.
As soon as you verify the contents of your deployment assembly pack, get them up to the server via a host to server script. Create a host to server script by simply writing the first Robocopy line from Figure 2 and modifying the paths so the source is your deployment assembly pack and the destination is your server deployment location path.
4.“Backup Files that I Used to Know”
It is important to get this next song stuck in your head because when you send files to the server, you also need to account for file backups of the “old” content that is already there. Your host to server script should make backups of old content before the new content from the deployment pack assembly gets sent to the server.
Figure 4 shows an example of how this is done. Notice that the first Robocopy line generates a backup file with the current date in a different location. There are other ways to format file names, but this is just one way to create a dated backup file with old content in it that you can easily reference if needed in the future.
Also notice that I don’t have all content mirroring (overwriting) from the server deployment location to the server deployment backup location. I wrote the first line that way because I don’t want the files to be overwritten. I want backup files to keep generating with all the respective subdirectories, so I do not have a /mir switch after that line. Now they’re just some files I used to know.
Figure 4: Host to Server script
5.“PowerShell™ Script of the Heart”
If you want to be extra crafty with your backup files, you may want to turn this song up. PowerShell™, another tool that is likely already on your computer, is a very powerful method for automating tasks through scripts. In fact, it is so powerful that its default settings actually prevent anything from running automatically with it.
Take note that with great power comes great responsibility. I want to address this in the topic of scripts because the .cmd files I’m showcasing have some limitations. More specifically, my backup files are rather large, and I want to compress and zip them. During my research, I did not see a way to do this exclusively with .cmd files and commands, so I looked into how to use PowerShell as another tool in my quest for automation.
As I mentioned, the default settings may prevent scripts from actually running through PowerShell itself. While you could change or bypass these settings, your IT department may discourage this action. For that reason, I looked into using PowerShell in an interactive way within my .cmd files.
Figure 5 shows how this is done. Keep in mind that for the sake of the screenshot, I just made the text wrap around to the next line. Otherwise, just placing content on different lines can make a difference, just like the order of content in your script can make a difference.
Figure 5: Host to Server script using PowerShell
While PowerShell itself can be an article topic all on its own, the key takeaway is that there is a source and destination defined for the backup file to grab files and ultimately reside, a means to compress said file, and then some code to rename the newly created zip file with today’s date.
I purposely showed a different way to format the date in the file name this time around. There are different possibilities in formatting the date because just telling the file to rename with the system variable %DATE% tends to come back with forward slashes (i.e., 03/08/2017), which is not allowed in Windows file names.
Now just add in your Robocopy line to retrieve and copy files from your deployment assembly pack location to your server deployment location at the end of this host to server script, and you won’t be singing the blues much longer.
6.“Somewhere Over the Network”
Somewhere over the network, your files will fly. And your automation dreams will come true . . . as long as you write this final server to user script that gets everything onto any end user’s computer.
This last step is crucial because your Autodesk software depends on it. The concepts and syntax are the exact same as Figure 2 except you are specifying the server deployment location as the source file path and the various file paths on your end user’s computer as the destination file paths. Just like %DATE%, you can use %USERNAME% as a “placeholder” in your destination file path when you are trying to deploy files to any end user computer (i.e., C:\Users\%USERNAME%\AppData . . .).
This script is the one that the end user can click on and run to get the latest and greatest from the server. One point I want to add is that the end user might not know what a script is or what it is doing. For this reason, I added in one last bit of code to my server to user script that actually notifies the user with a popup message box that the transfer of files is done. In terms of syntax on Figure 6, it can be inferred that “echo” is just a means of displaying something, and in this case it is displaying the text that the user’s AutoCAD MEP is up to date in a fun popup message box (Figure 7).
Figure 6: Server to User Script with Message Box
Figure 7: Message box
Keep in mind these scripts are just vehicles to transport files from one place to another. Additional setup may be required if you need AutoCAD on the end user computers to now read a bunch of new file locations for your custom content via a user profile. I created a copy of the AutoCAD shortcut and added a profile switch (See Figure 8), so it always runs the user profile I tell it to run.
The user profile drives a lot of the AutoCAD Options file locations, and it’s imperative that the end user’s AutoCAD setup is pointing to the correct file locations to run everything smoothly. I include this modified shortcut in my deployment pack for the end user to use when everything is deployed. Once these final points are squared away, you’ll have reached the end of the rainbow where there are all sorts of other opportunities to use scripts for automation.
Figure 8: AutoCAD shortcut properties
7.“Can’t Stop the Scripting!”
Scripting is my jam, but I am still learning ways to improve them for my automation goals. If you are looking for more information on how scripts work and how you can add more functionality to your own scripts for automating the deployment of custom Autodesk files, there are multiple forums and websites that talk about script syntax and more.
Because these tools are available already via Microsoft, it is beneficial to check out their Virtual Academy and other Script Center resources. All the script examples shown here are available as a download if you want to explore the possibilities. I have purposely kept the file paths as simple as possible because my goal is to illustrate the concepts without bogging people down with exact file paths that you need to ultimately configure yourself.
In short, scripts can be a great tool to add to your toolbox if you are looking to go from being dazed and confused to being dazzled and amused. So go out there and script away, but be sure to follow the proper rules of engagement to ensure you don’t wind up being an 8-track in an iTunes® world.
Example Scripts
Script #1 - DEPLOYMENT ASSEMBLY SCRIPT (copy & paste in a separate text file in Notepad)
Note: Don’t forget to change file paths prior to testing!
REM Copies all your custom content to the Deployment Pack
robocopy "C:\Source" "C:\Destination" /e /mir
REM Copies the Version of Deployment Pack
robocopy "C:\Source" "C:\Destination" "*.txt" /e /mir
REM Copies the Tool Palette Group File
robocopy "C:\Source" "C:\Destination" "Profile.aws"
REM Copies the Tool Palette Files
robocopy "C:\Source" "C:\Destination" "somefile*.atc"
REM Copies the Tool Palette Image Files
robocopy "C:\Source" "C:\Destination" /e /mir
Script #2a – HOST TO SERVER SCRIPT (copy & paste in a separate text file in Notepad)
Note: Don’t forget to change file paths prior to testing!
REM Creates Backup File of Existing Deployment Pack on the Server
robocopy "E:\Server Deployment Location" "E:\Server Deployment_Backup\Backup_%date:/=%" /e
REM Copies New Deployment Pack on the Server
robocopy "C:\Deployment Pack Assembly" "E:\Server Deployment Location" /e /mir
Script #2b – HOST TO SERVER SCRIPT-POWERSHELL (copy & paste in a separate text file in Notepad)
Note: Don’t forget to change file paths prior to testing!
REM Creates Backup File of Existing Deployment Pack on the Server Using PowerShell
powershell -command "& {$source = 'E:Server Deployment Location';$destination = 'E:\Server Deployment_Backup\Backup.zip';&'add-type' -assembly 'system.io.compression.filesystem';[io.compression.zipfile]::CreateFromDirectory($source,$destination)}"
rename "E:\Server Deployment_Backup\Backup.zip" "Backup_%date:~-10,2%%date:~-7,2%%date:~-4,4%.zip"
REM Copies New Deployment Pack on the Server
robocopy "C:\Deployment Pack Assembly" "E:\Server Deployment Location" /e /mir
Script #3 – SERVER TO USER SCRIPT (copy & paste in a separate text file in Notepad)
Note: Don’t forget to change file paths prior to testing!
REM Copies Deployment pack from Server to End User Computer
robocopy "E:\Server Deployment Location" "C:\End User Computer\Your Custom Setup" /E /MIR
REM Copies Tool Palette Group file to End User Computer
robocopy "E:\Server Deployment Location" "C:\Users\%username%\AppData\Roaming\Autodesk\MEP 2016\enu\Support\Profiles\Profile" "Profile.aws"
REM Copies Tool Palette Files
robocopy "E:\Server Deployment Location\Custom Files\Tool Palettes\AUGIWORLD" "C:\End User Computer\Users\%username%\AppData\Roaming\Autodesk\MEP 2016\enu\Support\WorkspaceCatalog AME (USImperial)\Palettes" "AUGIWORLD*.atc"
REM Copies Tool Palette Image Files
robocopy "E:\Server Deployment Location\Custom Files\Tool Palettes\AUGIWORLD\images" "C:\End User Computer\Users\%username%\AppData\Roaming\Autodesk\MEP 2016\enu\Support\WorkspaceCatalog AME (USImperial)\Palettes\images"
REM End of Script
echo msgbox "Your AutoCAD MEP is up to date!" > "%temp%\popup.vbs"
wscript.exe "%temp%\popup.vbs"
