Filtered articles: "Active Directory"

A while ago I explained how user passwords in common applications like Outlook are stored and encrypted. Unfortunately the tie of encryption and user accounts made a migration impossible for a number of migration scenarios.

Since the release of Profile Migrator 1.0 we have received a lot of positve feedback and feature suggestions. While we are working on adding support for profile migration from client computers in the next major release, the beta version of Profile Migrator 1.1 is out.

Bugs and Annoyances

ICA connections initiated over the ICA client object (ICO) SDK fail because 128-bit encryption cannot be enabled. Apparently, setting EncryptionLevelSession does not work. Annoyingly, this bug is more than a year old, was fixed in the ICA client 10.2 and reappeared in the current version 11.0. Bugs like this one are bad for the entire Citrix ecosystem, because they break cool tools like Citrix Quick Launch, xConnect and others I may not even know about. [Update 2009-09-30: this bug has been fixed in ICA client 11.2.]

Windows 7's version of Robocopy does not copy EFS-encrypted files to an unencrypted location on another computer. Even Explorer can do that. Vista's version of Robocopy was not so narrow-minded.

We all know that it is trendy to use a profile solution to rid Windows of some shortcomings of roaming profiles. And quite a number of you have looked at Citrix Profile Management (also known as User Profile Manager). In its current incarnation, UPM is configured using a group policy specifying the profile path. But similar to utilizing the "Set path for TS Roaming Profiles" for Terminal Services (soon to be Remote Desktop Services), this introduces the limitation that all users logging on to a server receive the same profile path – most most likely with some dynamically substituted components like environment variables or, in the case of UPM, fields from the user object in Active Directory.

Unfortunately, both solutions (UPM and "Set path for TS Roaming Profiles") are inferior to managing profile paths in Active Directory user objects. The latter enables administrators to distribute users across several servers or use components representing an organisational affiliation. Wouldn't it be neat to combine those to methods of maintaining profile paths?