UPS Worldship 2010 on Windows 7

Running UPS Worldship 2010 in a shared network configuration, i.e. Administrative station with Remote stations, with UAC enabled runs into an issue on Windows Vista and Windows 7.  I have personally only experienced this on Windows 7, mostly because we ignored Windows Vista entirely in our organization, but since the root cause is the behavior of UAC it stands to reason that Windows Vista may be similarly affected.

The following assumes that UPS Worldship is being run from an account that is not Administrator but is included in the local Administrators user group.  Much of the following can not be demonstrated while logged on as Administrator because elevation of Command prompts and some software is automatic and not a choice.

In a shared network configuration, UPS Worldship stores some of its files on a mapped network share.  After self-installing a patch delivered via UPS mail, the patch installer will demand UAC elevation, and when complete will automatically relaunch the UPS Worldship application, which will fail claiming to be unable to read an INI file that should be located on the shared network space.  Launching UPS Worldship manually after the patch is successful.

Attempting to launch UPS Worldship by using Run As Administrator produces the same error.  This makes sense, since the elevated patch installer would also launch UPS Worldship in an elevated state upon completion of the patch.  Other symptoms are errors while launching the UPS Worldship Support Tools, which demands UAC elevations and then tries to read configuration files from the mapped network share and fails with similar errors.

The root issue is exposed easily by opening an unelevated Command prompt and typing NET USE showing mapped drives as connected without error.  Then open an elevated Command prompt and again type NET USE revealing the same mapped drives as still present but broken in an error state, unable to connect.

This issue is commonly misreported and misunderstood as a symptom of user specific drive mappings, where a user who maps to network drives and subsequently logs off and back on as another user (perhaps Administrator) will not see those maps drives, as they are stored in the user registry and are therefore user specific.  It seems that Run As Administrator is a somewhat misunderstood function in Windows 7.  Some apparently believe this to be identical to using Run As in Windows XP and providing alternate credentials, typically a local or domain Administrator, after which the spawned process would be running under the alternate user context, complete with that alternate user's registry including mapped drives and such.

However, Run As Administrator in Windows 7 retains the current user context and registry but demands elevation for the spawned process instead.  The evidence of this difference in the Command prompt example above is simply that the NET USE under an elevated Command prompt shows the same mapped drives as seen in the unelevated Command prompt.  The user context, and thus the registry, is not changed, but for some reason the elevated security token can not access the mapped drives whereas the unelevated security token (provided by default) can.

If Run As Administrator on Windows 7 behaved as some people mistakenly believe it does, i.e. identical to Run As on Windows XP and using Administrator credentials, then the NET USE in the Run As Command prompt would not show any mapped network shares at all, unless of course you logged on as Administrator and mapped them separately.

The fix for this is documented at http://technet.microsoft.com/en-us/library/ee844140(WS.10).aspx.  Once the EnableLinkConnections fix is implemented, the elevated Command prompt will be able to access the mapped drives and UPS Worldship, and other programs that use mapped network shares, will function normally even while elevated.

I am somewhat disappointed, but not surprised, that UPS Worldship does not implement this fix as part of its installation.  The expectation from UPS is that Worldship will be executed from the Administrator account itself, not just from a user account that is a member of the local Administrators group.  However, the need for a mapped network share will typically force the use of a domain account as the primary user context for running Worldship, and best practices on the part of many Administrators will cause them to install the software while logged on as local Administrator or a member of their Domain Admins group, and then switch to their domain user for launching the software.  Unfortunately since UPS Worldship is self-patching, inevitably that domain user must be included in the local Administrators group for convenience sake, even though the software itself can operate otherwise.  It's one of many cases where developers take the easy way out for themselves by demanding local administrative rights for the logged on user and creating additional risk at the desktop instead of doing the work to follow security best practices and the Principle of Least Privilege.