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.

Handling Partial CUI Files From Vertical Applications

When managing multiple AutoCAD profiles and multiple vertical applications there are a few things that are important to keep in mind. One item is the CUI file that your profile points to. Let's say you have an AutoCAD based user profile that is pointing to the delivered acad.CUIX file that is located in your %RoamableRootFolder%\\support folder. When an AutoCAD vertical application is launched it often times partially loads a CUI file (or many) into the acad.CUIX file. When a CUI file is partially loaded into the acad.CUIX this definition takes place within the CUIX file itself and is not controlled by the profile. This means that any profile that also points to the delivered acad.CUIX file will also have the partially loaded CUI content. Even though the program may not be loaded the CUI content is which results in having "unresolved" CUI files: (this post uses Integraph's CADWorx Plant which is an AutoCAD vertical application).

Several vertical applications load themselves into AutoCAD by partially attaching their CUI(s) to the main AutoCAD CUI as shown above. This can be controlled but there are some downsides. One way to control this is to still create different profiles for each vertical application and actually point to a unique main AutoCAD CUI for each profile. The vertical application profile will then partially load into the unique AutoCAD CUI. The downside to this method is the users will not have any custom workspaces or content from profile to profile because the main AutoCAD CUI is different in each profile. Another way this can be controlled (which is the method I choose) is to manually unload unneeded partially loaded CUI files from the main AutoCAD CUI file.

To do this:

1. Launch vertical application X (in this example CADWorx Plant). Application X will partially load its CUI into the main AutoCAD CUI

2. Now launch AutoCAD into a different profile. Notice the CUI from Application X is still partially loaded but unresolved. This is because we are still pointing to the same main AutoCAD CUI file.

3. Open the Customization User Interface (CUI)

4. Expand the main AutoCAD CUI | Partial Customization Files node

6. Right click on any extra CUI files and select Unload

This does not cause any harm to the vertical application X. When it is launched again it will partially reload the CUI files if necessary.

This method of handling partially loaded CUI files from vertical applications does require the users to be responsible for maintaining their environment. One of the reasons I am comfortable with this approach though is having extra CUI files partially loaded is more of an annoyance rather than a disruption (in most cases). If the users choose to not manage their CUI files most vertical applications still function properly. A second reason I choose this method is it keeps flexibility in the environment by allowing users to customize their main AutoCAD CUI file and have those customizations available in all of their profiles.

Note, if you have your own custom CUI files that are being deployed from a network location using the Enterprise CUI file is a very streamlined way for managing these. This concept is covered in previous posts.

Creating an AutoCAD ribbon component

It might always seem that everyone is using the most recent version of AutoCAD, this is not necessarily true though. I work for a global consulting engineering firm and we have been on AutoCAD 2008 up until just earlier this year. The same goes for several of our clients and it is not uncommon for us to deliver packages in pre-AutoCAD 2008 environments.

This sounds archaic and out-dated but the real world has many variables that come into play and it is not feasible to always upgrade as soon as a new version of AutoCAD is released. Sure, if your company is working strictly with Autodesk products upgrades can be smooth and more timely, but when you rely on several different AutoCAD vertical packages and customized environments upgrades can become a time consuming effort that requires planning and strategy.

Regardless of what version of AutoCAD you may be working with I thought it might be helpful to do a post on User Interface (UI) and specifically talk about converting a pre-AutoCAD 2009 toolbar button to an AutoCAD 2011 ribbon component.

Let's say you have a custom toolbar in AutoCAD 2008 with a button that executes a command defined in mnl or dll that inserts a valve on a specific layer, breaks a line, allows rotation, etc. You want the same functionality in AutoCAD 2011 but you would like for your users to be able to execute the command from a custom ribbon. The command behind the button will not change, it can still execute with the same definition (unless it is in .net and the dll needs to be recompiled using the updated api files) we just need to make the command available via the ribbon.

To get started: Copy your custom content (cui, mnl, etc) to a new folder. Open AutoCAD 2011 and create a new user profile (Options | Profiles | Add To List)

To migrate a legacy cui file type in cui or select cui, User Interface from the Manage tab on the AutoCAD 2011 ribbon. From the Customize User Interface dialog click the Transfer tab. On the right side of the transfer tab (Customizations in New File) click Open. Note: to see .cui files (which are legacy since they are not .cuix) you will need to select .cui in the file type dropdown list.

Browse to the new folder created above and open the cui file. As soon as the cui file is open click the save icon and a new cuix file is created.

You can now choose how the architecture of your new profile will be built, I will partially load the new cuix file in to my main AutoCAD cui file. Later, we can come back and load it as the enterprise cui but while we are developing it we need to be able to write to it.

Just by partially loading the cuix file you will have the functionality that was in the legacy cui environment. This is all that is required to transfer functionality of a legacy menu system into a newer version of AutoCAD. Now let's create a new ribbon tab instead of offering only toolbars.

A quick note on the architecture of the ribbon. There is one ribbon with multiple tabs (these are the different areas that are selected at the top of the ribbon) each tab is divided into panels. We will create 1 new tab with a panel that contains our valve command. There is quite a bit more detail that can happen at the panel level such as sub-panels, panel rows, dropdowns, and separators but we will just focus on the ribbon tab and a single panel in this post.

Open the cui, scroll down to Partial Customization Files and select our custom cui file. Click the Ribbon node, right click on Tabs and select New Tab.

The ribbon tab is a container that will contain a panel or multiple panels. Create a new panel.

Populating a panel with commands that are already defined is simply a matter of dragging the command from the cui command list up to the panel.

To associate the panel with a tab drag the panel up into the tab

This association only needs to be created once. As the commands within the panel are changed (added or removed) they will reflect on the tab.

In order for the new ribbon tab to be available it needs to be toggled to display for the current workspace (similar to other toolbars, menus, and ribbon tabs).

The new ribbon tab now shows up in the main AutoCAD ribbon

And when it is selected the new panel (or panels) display with the commands that were added to each panel (Note, the order of the commands on the panel is controlled back in the cui by dragging the commands to their desired row and order).

When the new panel component is selected the same command is invoked! You have streamlined the migration of a legacy toolbar button to a new sexy ribbon component. Depending on how your new Ribbon/Tab/Panel layout ends up you may want to take the time to create new graphics for the components and if you choose to do so it is just a matter of pointing to the new image file from the ribbon element.

Manage custom files in multiple offices

Our streamlined environment now contains custom files, apps (dll and lisp), and other content we want our users to have available in their AutoCAD environment. We have explored some streamlined methods for maintaining this content in a central network location and getting the content to the users with minimal effort - basically a single desktop icon that points to our profile file (.arg).

In this post we will talk about extending this streamlined environment to multiple offices and still only maintaining one set of custom AutoCAD files. That last statement sounds contradictory but using an available Microsoft utility called Robocopy it is very possible and even easy.

Let's first look at the network structure for a multiple office environment. Let's say we have 3 offices (O1, O2, O3) each with its own server (S1, S2, S3), we want to first identify where our custom content will be stored on each server.

Office 1
\\S1\SLD\2010

Office 2
\\S2\SLD\2010

Office 3
\\S3\SLD\2010

Pick a drive letter that can be used consistently in each office (we will use S:\\) and depending on which office a user will be working in the drive letter should be mapped to the server for that office.

An easy way to manage drive mappings is to use a batch file that can be ran directly from a hyperlink on a web based tool such as Microsoft SharePoint.

Here is the code for the batch file to map a network drive:


REM batch file to map S:\ drive to \\S1\SLD\
@ECHO OFF
CLS
REM this line of code will disconnect S:\ if it is already mapped
NET USE S: /delete
NET USE S: \\S1\SLD\
echo S:\ mapped successfully!
PAUSE
ECHO ON

I did not add any error checking in this code but nonetheless this batch file can now be executed directly or by hyperlinking to it and the users' drives will be mapped to the correct location.

Now, each user at each office has the S:\ mapped and it points to the SLD folder which is on that office's local file server. If Office 1 is the master office that is where you will maintain the custom AutoCAD content. Any changes, additions, or deletions will be made on S1 (Office 1 server). We can use Robocopy to copy the content on S1 to S2 and S3. The Robocopy script can be executed on scheduled intervals so you can be assured that your master content on S1 is replicated on S2 and S3 as frequently as needed. The Robocopy script will be a batch (.bat) file. It can be created in a standard text editor and when ready should reside on a server with the Robocopy utility on it.

Here is the code to Robocopy a folder that contains custom files to each of the servers.


REM replicate CAD content to multiple offices
CLS
SET DATESTAMP=%date:~10,4%-%date:~4,2%-%date:~7,2%
REM Use variables to manage offices and servers
SET SOURCESITE=OFFICE1
SET SOURCESERVER=S1
SET TARGETSITE1=OFFICE2
SET TARGETSERVER1=S2
SET TARGETSITE2=OFFICE3
SET TARGETSERVER2=S3
REM Create folders for log files
IF NOT EXIST
 "\\%SOURCESERVER%\SLD\2010\replications\logs"
MKDIR
 "\\%SOURCESERVER%\SLD\2010\replications\logs"
REM Replicate CAD content
ROBOCOPY "\\%SOURCESERVER%\SLD\2010\Custom" "\\%TARGETSERVER1%\SLD\2010\Custom" /xf "*.bak" /eta /r:1 /w:15 /z /MIR /LOG:"\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%-%SOURCESERVER%_to_%TARGETSERVER1%-%TARGETSITE1%.log" /np /tee
ROBOCOPY "\\%SOURCESERVER%\SLD\2010\Custom" "\\%TARGETSERVER2%\SLD\2010\Custom" /xf "*.bak" /eta /r:1 /w:15 /z /MIR /LOG:"\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%-%SOURCESERVER%_to_%TARGETSERVER2%-%TARGETSITE2%.log" /np /tee
REM Generate Log File
ECHO DateStamp=%DATESTAMP% >  "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO SourceSite=%SOURCESITE% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO SourceServer=%SOURCESERVER% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO TARGETSITE1=%TARGETSITE1% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO TARGETSERVER1=%TARGETSERVER1% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO TARGETSITE2= %TARGETSITE2% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log"
ECHO TARGETSERVER2 =%TARGETSERVER2% >> "\\%SOURCESERVER%\SLD\2010\replications\logs\%DATESTAMP%_Information.log" 
SET DATESTAMP=
SET SOURCESITE=
SET SOURCESERVER=
SET TARGETSITE1=
SET TARGETSERVER1=
SET TARGETSITE2=
SET TARGETSERVER2=
PAUSE


You will notice there are quite a few parameters in the Robocopy command. This script will also generate log files which are handy to make sure the Robocopy is happening.

The key concepts in this post are having a common location in each office, a way for users to easily manage their drive mappings, and the same content at all locations all the time.

The way the Robocopy presented in this post will work is any changes, additions, or deletions to files in the master location will also take place in the target locations when the robocopy script is executed.

The Robocopy script is saved as a batch (.bat) file. You can then set this to run at a desired interval using Windows Task Scheduler.

This opens up a whole new realm of streamlining a design environment as we can now manage custom AutoCAD content in one location but share it with multiple locations.

Architecture of a Streamlined Design Environment

As I have mentioned in previous posts I am a fan of using the mnl as an access point to all custom AutoCAD menu content. Another popular method (which I avoid) is to place menu loading calls in the acaddoc.lsp file. My philosophy is to minimize modifying out of the box AutoCAD files and keeping as much custom content separated from delivered AutoCAD files as possible. This helps for a few reasons: one, upgrades are easier and smoother if all of your custom content is separate from the delivered AutoCAD files and can simply be reintroduced to the next version of AutoCAD. Another benefit is setting up a machine for a user is quick and easy and can be done by IT support in many cases (since out of the box AutoCAD is all that is needed and custom content can be introduced simply by adding a desktop shortcut that points to an arg file). Thirdly, this method keeps your menu sets organized so if you have multiple menu sets and AutoCAD user profiles they won't be conflicting with each other.

As with several areas in the AutoCAD realm, there is not necessarily a "right" or "wrong" way of doing something but rather an "optimized" way for each particular environment. The environment I work in includes multiple sets of standards for different clients and different third party applications so it is essential to keep my custom AutoCAD menu content organized.

Here is a flow diagram that represents an architecture that allows me to manage multiple environments for different clients and/or disciplines and keeps the custom content separate from AutoCAD:

This is a high level architecture but provides the framework for adding as much custom content as your heart desires...or rather, your clients/customers/users desire. We will look at the specific CUI architecture in a future post and talk about managing 3rd party applications and multiple AutoCAD based user profiles.

Streamlined Network Deployment

We have now created an AutoCAD user profile and saved it as an arg file. We looked at some of the key paths that are defined in the arg file: Main CUI and Enterprise CUI and we discussed how AutoCAD loads the CUI files that are loaded via these paths as well as an MNL file with the same name (and in the same location) giving us an excellent access point to load other custom content.

We created our own custom layer app using C# .net and we have a compiled .dll file for this app.

I think it will be worthwhile to re-cap how all of the above is tied together in a network environment and reaches the users. All that needs to happen in order for this to reach our end user is for the user to load an AutoCAD user profile that loads a CUI file that loads the MNL file that loads the .dll!

That sounds like a nursery rhyme but read it a few times, and it will sink in.

In a previous post we talked about passing a command line parameter when AutoCAD loads that will load a specified profile. If we get this AutoCAD shortcut to a user's desktop then when AutoCAD is launched from that icon our chain reaction happens and the custom layer app reaches our end user.

To automate this process you could consider executing a batch file that will copy the AutoCAD shortcut from a secure network location to the executing machine's desktop and no further client side configurations are required.

Here is the code that will go in the batch file:

COPY "X:\SLD\DesktopIcons\SLDMain.lnk" ^ "%userprofile%\Desktop"

This batch file can be executed through Windows Explorer but an elegant way of presenting it to your users is to use a web based intranet site (such as Microsoft SharePoint) and create a hyperlink that executes the batch file when clicked. Here is the HTML markup that will launch a .bat file.

<a href="X:\SLD\Configurations\SLD_Profile01.bat">SLD Profile</a>

The result of all this is the client machine can have nothing but an out of the box AutoCAD install and then a single click (to execute the batch file) will place a new AutoCAD shortcut on the client machine's desktop. This shortcut points to an arg file that then allows all of your custom content to be loaded automatically!