Updating from Civil3D 2015 to 2016. How do i migrate profiles and custom workspaces for each user?

[Brian Benton]

We are going to update all CAD users in the company across two locations from Civil3D 2015 to Civil3D 2016. Not many people have custom workspaces or profiles but at least half of them do. We have about 15 users in total across two offices. What is the best way to migrate everyone? Our IT consultant will be working with me to create a deployment package and they will be doing the actual install. Should we keep 2015 on each workstation and have each user use the migration tools? Or is there a better way to handle this?

Thanks.

[BlackBox]

How did you migrate users when deploying 2015?

What's changed to your environment since then?

Is anything else changing with the deployment of 2016, or shortly thereafter (be that Civil 3D specific, or Network related)?

Why is an IT consultant deploying 2016, when your employer already has one or more employees of your caliber?

Are you in a traditional server / client environment, using thin clients, or complete VDI?

Do you need / want to make any hardware changes to servers / clients before 2016 is deployed?

As example: server physical or virtual (RAID), or DFS Namespace storage capacity... change file server virtual drive from RAID 5 to RAID 10, add NIC teaming, etc)?


How's collaboration between offices; do you have a dedicated riverbed, or are you relying on VPN/Direct Access/IPSEC?

Is your IT consultant deploying 2016 as a traditional desktop/client application (installed locally), or deploying as a remote application using RDS?

Who is the contract manager for your Autodesk Account?

Have you already tested 2016 in a production environment?

As example: plotting to PDF (many changes to this aspect in 2016), or using other print device drivers (do you need to update your print server configuration or print-related GPO?), do you have any custom code / routines? Are you using an web, or collaboration functionality, and does IT need to modify server ports in order to enable/disable?


Once 2016 is deployed, are you giving users a period of time to setup, tweak, and check readiness before it is used for daily production?

Cheers

[rkmcswain]

15 users? I'd install 2016 straight OOTB, let each user do his/her own "migration".

Granted, still a lot of variables here, and I'm speaking from MY past experience.
Your situation may be different enough to warrant a different approach (see questions from BlackBox).

We have some apps that run in the background here to capture certain things for users (for example, the entries on the Places bar, in the file selection dialogs) and restore them on a new install, and I always encourage users to spend the hour or so to set up their menus, toolbars, colors, etc. from scratch - as opposed to migrating anything and risk bringing over something you DON'T want (such as a rogue path to something that doesn't exist)

[Brian Benton]

Thanks for the input. I was not here when the company updated to 2015 and neither was our IT service. I'm working with them on the deployment. Once set up they will be installing Civil3D to each workstation. The environment has not changed nor are there any changes planned at the moment. We are using a traditional server/client environment and we will not be making any changes to the server before we go to 2016.

Files are stored/modified locally then replicated to the other office's server.

Civil3D will be deployed as a traditional desktop client.

I have been running 2016 for over a month now.

[BlackBox]

No worries, Brian - sounds like you're in great shape then!

The only complicating factor then might be how rigid your office's standards are, in terms of plan production, as it relates to user's customizations.

With my former employer (large international firm), I deployed a profile that implemented the necessary aspects of the company's standards, but built in the availability for users to customize if they chose, and had it pre-mapped for them, to make it easy for those who did customize to do so again, without superseding corporate standards.

As example: http://forums.augi.com/showthread.ph...=1#post1204566


Cheers

[Brian Benton]

Our pipe catalogs, tool pallets, and printer files are in a central location on our server. I have to set up these files paths on each user's workstation manually. I made a profile from my workstation but when I loaded it on another users workstation the Ribbon was gone. What do I need to do differently to set up a profile that all users can use?

[BlackBox]

Our pipe catalogs, tool pallets, and printer files are in a central location on our server. I have to set up these files paths on each user's workstation manually. I made a profile from my workstation but when I loaded it on another users workstation the Ribbon was gone. What do I need to do differently to set up a profile that all users can use?

Pipe Catalog is specified in the application, and Registry saved as part of the user's Profile here:

HKEY_CURRENT_USER\SOFTWARE\Autodesk\AutoCAD\R20.1\ACAD-F000:409\Profiles\<YourProfileName>\Preferences\AeccUiNetwork100

... So configuring the Profile, exporting same, cleaning out any unwanted bits, and deploying that Profile will suffice.



Distributing Tool Palettes has been / can be a point of frustration - basically, you configure it, export it, ensure that the network locations for the Tool Palettes, dependent Blocks, Images, etc. are all included in SFSP, and then you can utilize them from the other clients. I'm sure that RK can provide more detail here from his site.



The Ribbon is part of the UI - for that, setup Main CUI primarily, your Enterprise CUI (if applicable), and any CUI's loaded as Partial, not forgetting any Autoloader apps with CUI.

Depending on your situation, you may want Main CUI local for speed, and reference in any 'common' CUIs from a network location (same for CUI-related images, dependent LISP, etc. being in SFSP).

I usually make a 'void' copy of the OOTB Main CUI, and customize the original, setting up partials, workspaces, etc. and then do the same for users when I deploy via Script/BAT, etc. which gives both the user the ability to do what they want thereafter, and you the ability to perform same automation effectively restoring to original deployment should they mess it up entirely (pretty rare).

[Edit] - Main CUI _must_ be located in a folder that is _not_ read-only to user's NTFS / AD (Active Directory) Account permissions, or they will not be able to modify.

[Edit] - If you use Enterprise CUI, this will prove to be invaluable.



[Edit] - Forgot about Printers; these are simply made available through Profile's applicable Options under Printer heading, and distributed as part of your .ARG (Profile). Just be sure that all dependent CTB, STB, PMP, PC3, etc. files are available on the network. You may want to recreate any critical PC3, PMP files using 2016 to ensure they work properly.



Just be sure that your IT Admin makes the critical network files/folders read-only for most users, so only those in CAD Admin role have Modify access per NTFS / AD Account & Security Group permissions. This will let your CAD Admin make necessary changes, without users being able to modify without CAD Admin even knowing (implicitly affecting others).

HTH

[rkmcswain]

Distributing Tool Palettes has been / can be a point of frustration - basically, you configure it, export it, ensure that the network locations for the Tool Palettes, dependent Blocks, Images, etc. are all included in SFSP, and then you can utilize them from the other clients. I'm sure that RK can provide more detail here from his site.

1. Make sure the location of the tool palettes is set up so that only you have write access.
2. Add the path to your support paths for tool palettes

3. Create and edit as needed, making sure locations of blocks, lisp, etc. are either in the SFSP, or fully/relatively pathed correctly.
4. Exit AutoCAD to write those changes to the server.
5. Add this location to your users machines. I do this via my centrally located Acad.lsp.
6. Any changes you make from this point on will be loaded on users machines the next launch of AutoCAD.

TP Groups are a different animal to control in the same manner.

[maporter]

I created a deploy in a folder location that can be replicated across 6 offices. (bandwidth issues doesn't allow me to deploy from one central location)
1. All custom files & folders are copied locally and replicated at user logon. (I'll explain later)
2. We have a custom profile that's sets everything under options, and a custom desktop icon that loads that profile when opening software if it's not already loaded.
If someone messes up their cad profile, we delete or rename it, and when software is opened again with custom button, correct profile is reloaded.
3. I use OOTB cui for main and our custom cui is enterprise.
4. Tool palettes are all shared location. (I found a tutorial once on how to set this up) We have a custom button for all our tool palettes including the default one. Click the button and the tool palette changes accordingly.

Custom files and folders.
We have/had a central network location for all of these, but we are migrating away from that for a variety of reasons.
1. A laptop user that doesn't have or loses access to the network location corrupts the profile, or you need to create separate setups for that scenario.
2. Having CAD access this network location a gazillion times a day (you're never really sure when and how much) can create a lot of network traffic and is more difficult to troubleshoot.
We are migrating to a process where all custom files/folders are copied locally, and that data is replicated at user login using Robocopy and Task Scheduler.
The custom data doesn't change that often, so the replication takes 10-15 seconds at the most. Most of the time, the user doesn't even know it happened.

[BIG-AL]

We just did 8 2013-2016 and it was pretty painless, we used a USB to load.

Now the steps
We had each user who does have their own workspace to make a screen capture or write down their toolbars.
1st step was Config and set trusted paths, a nice option is the use of the 3 dots ... so only need top level for a directory on the server containing all our support items. G:\server1\Autodesk\supportfiles... The 3 dots hint was found on the Cadtutor forum a real time saver.
The we run a lisp that configures all our settings rather than manualy entering them all in Config, similar do a menuload and load standard menus, use -toolbar to get 1st toolbar displayed and then let each user set their toolbars to the way they like. Lastly save each users named workspace. Around 20 minutes after software loaded.