Manage scripts and package versions, Deploy to the company, Secure your dynamo graphs, while letting people experiment and learn if they are interested.
Goal of the deployment setup:
Develop the graphs out of public view and test them before deployment
Get “official” published graphs onto all the PCs, and keep them unaltered
Make the “official” published graphs easy to find
Keep all PCs up to date with changes in graphs and packages
Allow for the curious to explore, experiment and develop with Dynamo if they want
Keep the “official” published graphs unaltered
Our development team for official dynamo graphs has enough knowledge to not need this setup. They manage things manually on the development PCs. To deploy to the rest of the organization we have created the graphs, package libraries, and scripts similar to what other people have posted before. We chose to put the official content right up front in dynamo player so there is no browsing needed to find the company graphs. The setup we describe also does not need to have IT involvement. Having said that though, this setup is not trying to get around IT, it is meant for those that may also be IT but don’t have all cool tools or knowledge to deploy to an entire office or multiple offices.
This setup for distributing dynamo has a read only library on a server for storing the content that will be pushed out to the PCs using batch files.
You will need a common location on a server to store the precious functioning versions of graphs and packages. We keep them in a location that only the dev team can write to, alongside the Revit family libraries that everyone has mapped already. The batch file scripts copy things to the local PCs from this location. To make the official graphs easy to find, they get copied to the default dynamo folders on the local PC drive. To keep all the PCs up to date when changes are made to the official graphs and packages we run the updater batch file script at login. The updater script copies the official items to the PC. In order to allow for people to play around or develop on their own, but still have the content easy to find, we also heavy handedly remove the “history” that dynamo player keeps for last used folders. This puts dynamo back to a default out of the box look after each login/update. So, we have an official storage location, a login script to update things to the local PC. Now let’s look at the details of how we chose to handle all this.
The locked down official library on the server looks just like the folders that dynamo installs on the local PC to make it easy for us humans to keep track of things. We start with \Dynamo Revit and the main directory. We keep Logos (for Data-Shapes), the batch file, and a couple Dynamo Core maintenance graphs here. Our base version of dynamo is 2.0.3 and since at that level it is not installed with Revit we have the installers here for people using older than 2020 Revit to install with.
Dynamo 2.0.3/2.0.4 runs in Revit 2018 & 2019 and graphs that work with this version are kept in the Dynamo Revit\2_0 folder.
Dynamo 2.3.1.xxx runs in Revit 2020 and the graphs that work with this version are kept in the Dynamo Revit\2_3 folder.
Dynamo 2.5/2.6/2.7/2.8 runs in Revit 2021 and the graphs that work with this version are kept in the Dynamo Revit\2_5 folder.
We started creating folders for each update, but we found that our graphs did not need to be updated so we stopped and pull everything from 2_5
Dynamo 2.10.xx runs in Revit 2022 and the graphs that work with this version are kept in the Dynamo Revit\2_10 folder.
Packages that work for our graphs have a similar folder structure and the specific package version that works is kept in here. The package library was created by copy/pasting the package files from one of the development PCs. Many packages are backward compatible, but may need a little graph updating, so the specific packages that we know work are kept here by version for distribution. Since we usually deploy to a PC before anyone becomes interested in dynamo, our favorite packages are already available to the PC when anyone wanting to play with graphs starts, and they will already have most of the packages they need. Since we are constantly updating and checking functionality we have not had people install a package that was newer than the published version so far.
You can see John Pierson’s !Template starting point file here too. We send that to the PCs in case anyone wants to make graphs. The dynamoSetup.bat is the file that uses robocopy to send the official content to the PC. The dynamo graphs that start with an underscore here use dynamo core only. One will display a dialog box that explains how our team uses dynamo and provides a link to send people to the documentation for all the graphs. The other allows for an update to be run without having to reboot the PC. Before we look at the robocopy let’s look at where dynamo likes to put things.
The folders we will use are hidden directories and generally not visible in file explorer. We can access them using the system variables that come with the Windows. The library of sample graphs that ship with dynamo is stored in C:\ProgramData… . The Windows system environment variable for that is %programdata% . If you type that into the file explorer address bar it will take you there. We are going to copy the official published graphs to this location so they can be found without any need to browse around to other folders.
Location of Revit 2022 default library
%programdata%\Autodesk\RVT 2022\Dynamo\samples\en-US\Revit\DynamoPlayer-4
Location of Revit 2021 default library
%programdata%\Autodesk\RVT 2021\Dynamo\samples\en-US\Revit\DynamoPlayer-4
Location of Revit 2020 default library
%programdata%\Autodesk\RVT 2020\Dynamo\samples\en-US\Revit\DynamoPlayer-3
Location of Revit 2018, 2019 default library **Notice the folder structure change
%programdata%\Dynamo\Dynamo Revit\2.0\samples\en-US\Revit\DynamoPlayer-2
The other two locations are in the C:\users folder. Applications write files to a directory called AppData and at various levels of use we will need both the Local and the Roaming directories. Dynamo stores the Packages that people install using the Package manager tool in AppData\Roaming . The Windows system environment variable for this is %appdata% .
Destination for packages will be:
2022
%AppData%\Dynamo\Dynamo Revit\2.10\packages
2021
%AppData%\Dynamo\Dynamo Revit\2.6\packages
2020
%AppData%\Dynamo\Dynamo Revit\2.3\packages
2018-2019
%AppData%\Dynamo\Dynamo Revit\2.0\packages
Our heavy handed reset back to the default dynamo player setup will occur in the AppData\Local directory. The system environment variable for this is %localappdata% . This is heavy handed and so far still works, but future releases may make changes to this. Dynamo player can remember the last folder that you used to run a graph from, and it does that in this area. When dynamo player has not ever been run the following User data folder is empty. Once someone uses dynamo player, browses out to another folder, etc. That history is stored in a particular folder for each year version. In order to allow people to play around and experiment, but maintain the ease of use we are building in, we wipe this folder with our update scripts. This has the effect of setting dynamo player back to a state of never being run. There is a .xml file here after using dynamo player with data in it, but without some major IT work there is no way for us to make sure the official published content stays prominent in the player.
Resetting dynamo player to default locations:
2021 -2022
%localappdata%\dynamoplayer-4\User data\dynamoplayerinstance 1
2020
%localappdata%\dynamoplayer-3\User data\dynamoplayerinstance 1
2018-2019
%localappdata%\dynamoplayer-2\User data\dynamoplayerinstance 1
Now to the dynamoSetup.bat file. This file never leaves the server and is stored in a read only directory. With IT help it can be made to run at login. Without IT help we will use the local PC startup folder. To create a batch file, use your favorite plain text editor (notepad++). We can start with @ECHO OFF , but it may not behave because of the way we will run it later. Comments can be entered by placing :: (double colon) at the start of a line of text. TITLE and some title text will put a heading in the copy dialog box if/when it shows. This can alleviate some suspicion if someone is not expecting our updater to run. I left ::PAUSE commented out in the image. I keep this in the batch file to use during testing. I can uncomment each PAUSE and the script will wait for me to hit a key until progressing any further. This lets me check to see if what I want to happen is happening without performing the entire script. Comment it out for the production version so there will be no interaction required.
Section 1 we see robocopy is used to copy all the packages that we know work with our graphs. robocopy “source” “destination” /switches
robocopy “\servername\01 REVIT\TOOLS\Dynamo Revit…” is the location on the server in the image above that we copy from (source).
The destination follows and is “%appdata%…” depending on which version. You can see that I pull source data from 2.5 and send it to two destination folders. This is because we started to change per dynamo version, then found it was not needed.
/e /z /r:4 /mir are the switches used. /e uses subfolders, /z copies in restart mode in case a connection is disrupted, /r:4 will retry the copy 4 times before giving up, /mir will mirror the exact directories on the source to the destination, including adding and removing files and folders. Search for “robocopy switches” online for more information.
Section 2 uses robocopy and mklink to send dynamo graphs to the local PC. The robocopy part is easy, but in this case we left off the mirroring so that the dynamo installed stuff doesn’t get deleted and I don’t have to control what is there. I am just adding my stuff to the directories. mklink is interesting and this part of the script requires that the batch file be run using admin credentials. Since we are not using IT, this will happen with the startup login script later and will pop up the User Account Control warning before running the script. It will use the person’s local admin control of their user folder to allow the script to run. mklink creates a blank file that refers back to the ‘linked’ file. You can see we are using this a couple of ways for organizing the graphs.
First, the new file we create on the local PC acts just like any other file for the person using file browser. Notice the file extension .dyn. The operating system will see this as an actual dynamo file, but it is really just a 0 kilobyte pointer file. Second, we added ##_ to the beginning of the normal graph name. This allows us to float the published graph above all the dynamo installed sample graphs in dynamo player. This numbering also allows us to organize the graphs into playlists using sequentially numbered graphs that can be run one after another. It also allows us to have one actual .dyn show up in the list of graphs several times. We use 00_ for general run at anytime graphs. The link file name 00_help and information.dyn will always be at the top of the list in player because of the naming we use. As an example of another number sequence 00_Create Default Views per level.dyn is also used as part of the 90_'s sequence playlist. The 70_ & 90_ sets of dynamo graph playlists we have are for different kinds of project setup that need to happen in a particular order. Third, using a pointer file to link to the official graphs means that no one can mess with the published graphs because they are really on the server in a protected folder. People can open the pointer files in dynamo, edit them and otherwise play around, but they are not messing with the actual deployed graph. If anything gets messed up, we can just delete an existing mklink pointer file here and the update script will create them again. The structure for making the links is: mklink “destination” "source" , but remember that elevated privilege is needed to create linked files. We are making our pointer files in the %programdata% folder where dynamo has already installed all the sample files. Our source files are coming from the server location in the image above.
Section 3 is where we reset dynamo player so the pointer files we just created are always displayed, and any browsing action by the person using it has been forgotten. Our reasoning for the reset is to keep the official graphs front and center. If someone is browsing to run other graphs, then they are knowledgeable enough to do it again later. rmdir is used to remove the directory. The command switches /s & /q will remove all subdirectories and files & do it quietly without complaint or warning. The structure for the command is rmdir “path” /switches , we changed it a little based on experience and it works fine. This was for clarity to the human. We are removing the directory " dynamoplayerinstance 1 " and all subfolders and files. The batch file script ends with CLS to clear any screen that popped up.
We now have established some maintained libraries, figured out where to send them, and have a batch file to launch and do the sending. We need to be able to have this launch at login without the help of IT. Windows has a startup folder that will do things when the PC starts during login. We will use the common startup folder to locate the files we want to run at login. You can get to this using the RUN command, windows logo key + R , then type shell:common startup
to get to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp or %programdata%\Microsoft\Windows\Start Menu\Programs\StartUp
We are going to have to get 2 files into this directory. You can email the files to someone with instructions, you can connect over the network and place them there, you can zip them up with the folder path saved, you can use InnoSetup to create an installer. The choice is yours. Once they are there they will run at login. Because we used the mklink command, which needs elevated access, we will need to place 2 files in the startup. A batch file and a shortcut file. We need 2 files because of the way Windows handles what gets executed from this folder. The first is simply a batch file that will run our shortcut file. Any windows shortcuts to software executables placed here will run those pieces of software at startup, but Windows ignores shortcuts set to run as Administrator. The other issue is that we cannot set a batch file to run as Administrator. So 2 files will get the job done.
Create a new text file to turn into a batch file. In this file all we need is call “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\dynamoSetup.lnk” I named the batch file dynamoUpdates.bat . Create a shortcut to your main dynamoSetup.bat file that is on the server. After the shortcut is created, and before sending it out, right click the shortcut file to get to properties (1) and use the advanced button (2) to set the shortcut to run as Administrator (3). Now you have the two files created to place in the startup directory. Send them out.
So when completed the Startup folder will have dynamoUpdates.bat that will run the shortcut file dynamoSetup.lnk with elevated privileges. Depending on how much control IT has limited on your PCs this should work to create your own login script to make the linked file playlists. User Account Control will pop up at each login warning about the running of our update batch file. Use your preferred method to get these files on the PC of people that you want to run dynamo.
Your mileage getting this to work will vary due to how PCs may be configured. IT has many ways to secure the PCs in your organization that can stop this process. This example is not meant to get around IT security measures, but rather to help get things done when IT doesn’t have the time or willingness to get you a login script, or you are IT and architect and BIM manager… If the automation of the startup folder does not work because of security restrictions, you can try manually running your server stored batch file using an elevated command window if you have access to that.
This has gotten us copies of the known working graphs and packages to any PC that has our 2 files in the startup folder. This process has been around for a while, but now with the advent of more add-ins and new versions, we can make dynamo even easier for people to use. Orkestra is an add-in by @Mostafa_El_Ayoubi that helps you manage dynamo content. It has a free version and a paid cloud version. If we want to use the free version to show and run the content we just deployed we can do that too. You will need to download and install Orkestra and get a few things in place before having people download and install it on their PCs. In order to preset the local workspace and/or PlayLists for everyone, you should get the .xml configuration file on the PC before they install Orkestra. You can do it afterwards, but will lose anything that they configured. You can also edit the file after the fact to place your preferred workspaces if needed.
Orkestra keeps the configuration file in %appdata%\Orkestra. Grab a copy of that UserSettings.xml and customize it to have your preferred local workspaces show up after install. There are tons of lines that could be in this file, but we want a relatively blank copy for deployment. Place the text that is between the tags WorkSpace /WorkSpace in your config file to the copy of the config file that will get deployed. Leave most of the other things blank since they start to refer to user folders. Now save this partially configured Orkestra .xml and use your batch file to send it to the PCs with all the other goodies.
The robocopy command that we would use for this .xml file is different because we want to avoid overwriting things once someone has used Orkestra. robocopy “source” “destination” [file] /switches
robocopy “\\servername\01 REVIT\TOOLS\Dynamo Revit\Orkestra” “%appdata%\Orkestra” UserSettings.xml /copy:dt /xo /z /r:4
This time we have our source, the mostly blank xml file stored in a locked place …\Orkestra\UserSettings.xml
The destination, %appdata%\Orkestra
Then the actual file name since this is just a single file we want to copy, UserSettings.xml
Then our switches, /copy:dt will leave behind file permissions. Maybe good since we got this from a user folder. /xo Excludes copying files older than the copy in the destination directory. We don’t want to overwrite anyone’s work. And the previous /z /r:4 we saw above.
I hope this helps anyone that has been struggling with deploying to the entire office or offices when they don’t have IT support.
