Firstly, a philosophical digression. The function of Ghost's integrated User Migration and the Symantec User Migration Wizard is - user migration, roughly defined as the moving of a specific users files and settings from one machine to that same user or a different user on another machine. Although I think Ghost/User Migration is capable of addressing your needs, Some of the issues you are trying to address fit more closely into deployment and configuration.
Having said this, thank you for pointing out exactly what your needs are. There is potential to extend the user migration solution into this area. This is something we need to follow up. Certainly it would make your task much easier. Deployment, configuration and management is what Ghost is all about after all.
Anyway, on to your specific questions as they relate to the current version of the GSS User Migration and Symantec User Migration Wizard.
Most of the user configuration needs you have identified can be served by using the wizard to capture a model user (which you wouldnt use for anything else) from a source machine with your required settings, then logging on as the target user on the target machine and restoring the model user in that context.
> Console Command Execution. Havent had a chance to explore this - are these like macros or batch files that you run (from the console) on client machines?
Pretty much. If you create a new task in console there is a checkbox on the general tab called Command Execution. If you tick this, the command execution task step tab will appear. Im not surprised if it has been missed, the way the tasks are displayed, you need to enable the checkboxes on the general tab before the individual task steps appear. If your command requires files not normally present in a windows installation (like a custom script for example) those can be transferred to the machine (as part of the same task) using the Transfer Files step.
As an aside, the command execution step is always the last step executed. To see the order in which task steps are executed, right click the task and choose Task Scenario Report.
> So basically what you're saying is that since the restoration is attempted by the "System" account, the user's credentials can't be used to validate access to remote resources (like mapped drives); and thus they aren't currently restored? ...Just trying to get a handle on exactly what the limits are.
Thats true for shortcut validation during managed Ghost User Migration using the console. If you are running the Symantec User Migration Wizard though, shortcut validation will occur in the context of the logged on user you are using to perform the restore operation.
We are looking at how we might provide an option in future releases to restore shortcuts without validating them, or perhaps some kind of advanced validation.
> I can't get the company to agree to mapping people's "My Documents" folder to a network share/drive (using AD/Domain policies). So we have people that use "My Documents" instead of the network share for their work files. In an attempt to nudge them in the proper direction, I typically rename the start-menu "My Documents" item to "Personal Documents" in order to differentiate it from their "Work Documents" network share (this start-menu change usually automatically propogates through some other system-level menus/UI; though some applications still use the traditional "My Documents" name).
Ah, o.k. This is something more than a simple rename operation. When you rename this item, windows actually makes a change to the registry, but the underlying name of the folder isnt actually changed. This is probably a good thing. The approach you have chosen will not cause any problems for any non windows logo compliant applications which might want to access this location using the absolute name.
For Windows XPSP2, the change made to the registry by windows is located under:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{450D8FBA-AD25-11D0-98A8-0800361B1103}
The default value for that key is unset. When the item is renamed under windows, the default value is set to the value you specified. Eg; Personal Documents.
After setting this key you can capture it by specifying it in the Registry tab of the console user migration template. Do not include child keys as they are sometimes machine specific for this particular clsid. The console migration template can then be exported for use with the wizard. Drop it into the Program Files\[]\User Migration Wizard\XML directory on the client side.
> The drive mapping in question is established via a login-script, and is specific to each user (basically its a Domain-level script establishing a "home directory" on the network). The shortcut is usually created from the drive letter/mapping. I'm guessing that your answer here is going to be that such an operation isn't supported in the User Migration tool, but I've been surprised already by some of the functionality of GSS!
Again, command execution should be able to handle this task. A logical place for this is as part of the script above. Basically, you will need to script the creation of a shortcut, or alternatively just file transfer it and copy it to each user enumerated by the script.
If you are logged on at the client in the user context anyway (to restore the model user) a script written for execution in that context will be much simpler and will not require user enumeration.
Let us know how your implementation goes.
Thanks,
Xan