Updating a Network User Profile

Maintaining network based AutoCAD user profiles is a simple, organized way of delivering any content you need your users to have. Once the main architecture is in place you can make updates to a profile and all users will instantly get the update...or will they?

If we have an AutoCAD profile on a network location that everyone is pointing to (maybe from an AutoCAD desktop shortcut) the first time the profile is loaded it will define the profile name on the computer's registry under the AutoCAD Profiles path. This then ensures that all users have the same settings that are defined in the profile.
The way this behaves after the profile has been loaded in the registry is when the icon is launched again AutoCAD checks to see if the profile being pointed to in the desktop shortcut is already defined on that computer. If so, AutoCAD does not re-define the profile it just makes sure to set that profile current. The downside to this is if you make a change to the profile (for example add a support path) this does not automatically get deployed to machines that already have the profile defined.

There are two ways to make sure everyone gets the update:
1. Delete the profile from the users' local machines then when the desktop icon that points to the network profile is launched, the profile is re-defined with the most recent updates.

2. Change the actual profile name. This will then tell AutoCAD that this is a new profile that is not defined on any one's machine yet. This method works without having to update the custom AutoCAD desktop icon because changing the profile name happens within the .arg file - the filename of the .arg file is irrelevant.
Let's walk through this from the beginning to make sense of this:


I have created a network based AutoCAD user profile that I want to load for all users. My new profile only has an additional support path and an enterprise menu file definition.

My choice of deployment was to create a new AutoCAD desktop icon that points to the custom profile (.arg file). Note: this location typically would reside on a shared network drive.

Once this icon is on each desktop (maybe automated via SharePoint) we are set to manage our custom network environment.


Note, at this point I have copied the desktop icon to my desktop but the AutoCAD profile <<SLD_2011>> does not exist on my machine yet.

When I launch the icon for the first time the AutoCAD Profile is defined in my local computer registry

Here is how the Options dialog looks in AutoCAD with the custom profile now loaded on my computer.

So now, we are to the real topic of this post where we want to make a modification to our shared network user profile. Let's say we want to add an additional support path (Support2).

This is great for anyone that has not yet loaded this profile but what about for machines that already have the profile defined? When these users launch AutoCAD into the custom profile their profile on the local machine does not get re-defined so therefore they do not get the additional support path. The key here is the profile name. AutoCAD checks if the profile is already defined within the registry and if so the profile is not updated. But if we change the actual profile name after making the change then AutoCAD will recognize this as a brand new profile and we can be assured that the change will be deployed to all users because they will actually be creating a new AutoCAD user profile.


To do this we do not need to change the filename of our .arg which also prevents the need for changing or modifying the desktop icon that is already on user's desktops. The change is made only within the .arg file itself.

Now, even though I have the original profile already defined on my computer when I launch the custom AutoCAD shortcut again the new profile is created (and made current) and I now have the additional support path that was added.

You might notice I updated my profile name with a new version. This might be a strategy you want to adopt from the beginning. If so, you can include a version indicator in your original network profile.


This provides a streamlined method of managing and updating a network based AutoCAD profile. The power of this method is everything is controlled from a single network location and the local workstations do not need to be touched in order to deploy updates to AutoCAD user profiles.

"Invisible" problems in AutoCAD script files

Even with all of the AutoCAD programming enhancements and version upgrades over the years, script files still can provide a streamlined way to automate AutoCAD functionality. Another attractive feature about script files is they are simple (and fun!) to create.

A script file is essentially a macro that will execute a series of AutoCAD commands. Repetitive tasks in AutoCAD present an opportunity for automation. Automation can mean everything from developing a high-powered .dll application, to an AutoLISP application, to a script file.

There is not a lot of syntax to worry about in a script file (except for invisible problems...keep reading) and the contents of the file should mimic the command line in AutoCAD.

Here is an example of a script file that creates a new layer, assigns the color, and sets it current:

(Note: the green comments are not part of the actual script file. Script files can be created using notepad and saving as a .scr file extension)

-LAYER      use the dash to suppress the command dialog

N           choose new option

SLD-EXAMPLE define layer name

C           choose color option

CYAN        define color

SLD-EXAMPLE specify layer to receive color

S           choose set option

SLD-EXAMPLE specify layer to set current


Now, the reason that inspired me to write this post is an invisible problem when troubleshooting a script. What I mean by invisible are blank (space) characters. AutoCAD treats the "space" character as an Enter (remember, it is identical to the command line in AutoCAD). If there is an extra "space" at the end of one of your lines in the script your command sequence will be off track. The best way to troubleshoot this is to notice where the script is breaking during runtime and then look near that line of code for an extra space. Another invisible problem is if there is not an EOL (carriage return) at the end of your last command the script file will not close out completely when executed. Remember to always enter a carriage return after your last command. Which leads to the final invisible problem which is if you have more than 1 carriage return at the end of a script file. This will invoke the last AutoCAD command that was executed during the script file.


These invisible problems have caught me off guard a time or two so hopefully this is a helpful clarification (or reminder) to be careful about extra spaces and carriage returns in your script files.