I'm going to assume Windows NT4 TSE with MetaFrame 1.8 for this document, since, at the time of writing, it is the most common platform. The principles are the same for WinFrame, Windows 2000 or XP and MetaFrame XP, but the tools used and some file locations are different.
The most effective form of profile for most businesses is the roaming profile. These can be easily implemented, and allow for a wide range of administrator control over user activity when combined with system policies. The added advantage is that roaming profiles can be made mandatory, thus allowing for even tighter control. This is of obvious benefit to educational establishments or public access kiosks.
In the ideal setup, the server holding the users' profiles will be separate to the MetaFrame server. This central profile store is not to be confused with the locally cached profiles to be found in %systemroot%\profiles (%systemroot%\Documents and Settings on Windows 2000). It is simply set up by sharing a folder (eg called "profiles") from a file server. For preference, this folder should be in the root.
To utilise this share, go to Server Manager on the File Server (located in Administrative Tools\Common), and, under the Computer menu, select Shared Directories. Create a New share to the folder you have created, and set the Permissions to allow your MetaFrame users Read and Write access.
Next, log in as the Domain Administrator on one of your MetaFrame servers. In User Manager for Domains, click on the Profile button for the users you wish to assign roaming profiles. In the Terminal Server Profile Path (if you are not on a Terminal Server you will not see this box!), enter the path to your share, including the %username% variable eg \\myserver\profiles\%username%.
When the user first logs onto a Terminal Server, he/she will get a copy profile from the Default User profile on that Terminal Server. If this profile is wrong, then the administrator must amend it in one of two ways.
1) The Default Users' ntuser.dat can be loaded into the Registry and edited directly. This is not my favorite option, since all manner of things could go wrong - and it's time-consuming.
2) Create a new user with administrator rights, log in *(see note below) and modify the profile until it is as generic as it can be (ie don't set an Outlook profile, or all users will get that Outlook profile!) and then log out. Copy ntuser.dat from that user to the Default User, and all users will get identical settings the first time they log in. ++(see How It Works below)
* A couple of tips here before you log in as the new default user;
1) Stop Internet Explorer from going through its initial routines by editing the following registry key; HKCU\Software\Microsoft\Active Setup\Installed Components - delete everything below this subkey (ie leave the Installed Components key intact).
2) Stop My Briefcase from appearing by adding HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\RunSyncApp REG_DWORD 0, and rename the file %systemroot%\System32\syncapp.exe to syncapp.old
3) Use System Policies to lock down access to "dangerous" applications, and to remap user file paths to other shares on the File Server. Files stored inside roaming profiles can cause "profile bloat", which leads to excessive login times and other user problems.
Give the user appropriate permissions, and test your new roaming profile by logging on as that user from a variety of clients at different locations.
To make the profile mandatory, simply rename the ntuser.dat of that user in the central profile store to ntuser.man. If it will be mandatory that the user reads the profile from the server, and if logon will be denied unless this is the case, add the extension .man to the User Profile path; for example:\\myserver\myshare\mydomainuser.man (From Microsoft's whitepaper, part 2. http://support.microsoft.com/support/kb/articles/Q185/5/87.ASP.
++How It Works - Roaming profiles
When a user logs in to a Terminal Server, the Terminal Server looks to see whether there is a local copy of a profile associated with that user. If there is not, it checks, via the users' login credentials, whether there is a roaming profile available for that user.
If there is no roaming profile available (and there won't be the first time a user logs in), then the Terminal Server copies the Default Users' profile to a folder with the users' login handle. It also copies the contents of the users' ntuser.dat to HKEY_USERS in its registry, under the users' SID.
When the user logs out, and roaming profiles have been implemented, then the Terminal Server will copy the locally cached profile to the profile store location, and unload the users' SID. This cenrally stored copy will be downloaded the next ime the user logs in.
If the user does not log out cleanly, or disconnects leaving files open, then the profile may not copy to the central store correctly, and the SID may not be unloaded. This is particularly a problem with Terminals, where users will choose the logoff option, and switch the Terminal off before it has completed the full logoff process.
The next time the user logs in, in this case, a new local copy will be created in the folder %systemroot%\profiles\newuser.001.
Generally, the only way to clear these profile copies down is to reboot and then delete the folders. Alternatively, the files that the user is still holding open can be tracked down using Server Manager on each of the servers that the users has opened files from, and closed individually. The profile copies can then be safely deleted by the Administrator from the My Computer icon, right-click, choose Properties, User Profiles (wait a while if you have a lot of users). If the profile can't be deleted, then the user still has files open somewhere.
To restore a corrupted or just plain wrong profile, often the only way is to delete the centrally stored copy and have the Terminal Server create a new one. If this is wrong, then you need to update your default user again. If you have many load-balanced Terminal Servers, check that the default user is identical on all of them.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.