Roaming/mandatory profile locations

Discussion in 'Windows Desktop Systems' started by daveburger99, Aug 31, 2002.

  1. daveburger99

    daveburger99 Guest

    Where does XP Pro look to find a roaming/mandatory profile when logging into a Windows 2000 network (default location)? Which mmc snapin, or other utility would I use to change the default location that XP Pro uses. I have created a profile on the XP machine and copied it to the 2000 Domain Server SYSVOL folder but when I log in I get the following: "Windows cannot locate the server copy of your roaming profile and is attempting to use a local profile...." How do I make XP machine use the SYSVOL folder and the mandatory/roaming profiles I've created?

    Thanks for the help
  2. Rootz

    Rootz Guest

    I assume yours is a domain user account.
    If so, the account information resides on domain controllers.
    What you have to do is share a folder on a domain member server (or domain controller), then copy the account folder into that share.
    Using Active Directory Users and Computers (on the W2k Server) doubleclick the domain user account you want to have a roaming profile and select the *Profile* tab.
    Type the UNC path to the newly created share (i.e: \\servername\sharefolder\accountfolder) as the profile path, must be a network path, not absolute (i.e: C:\sharefolder\accountfolder).
    All you need to do is on the server, not the client. If the network path and share permission are ok then you got a roaming profile, means that you have the same user settings/desktop/favorites whatever domain machine you log on to.

    BTW... the SYSVOL folder is where Active Directory Database is stored, you should not place home directories in there.

    Hope this helps.
  3. daveburger99

    daveburger99 Guest

    Thanks for the help. A second question. This is a school where there are approx 350 students. They have user accounts in Active Directory on the Domain Controller(s). Is there a way to import the user database from AD in Windows 2000 server to the AD on the laptops (XP Pro), or is it a better idea to use the guest account to supply a generic local login. The idea of re-creating all users on every XP based machine is daunting to say the least. I have spent a great deal of time browsing Microsoft's TIDs for a way to perform this task easily - but no luck.
    Thanks again, the profiles work as long as the user exists in AD on the XP machine.
  4. Rootz

    Rootz Guest

    I guess we should do a step back on the various kind of user accounts.
    It may make the problem clearer to you.

    Local User Account - is a user account you set up on a single client machine. The user can only log to the machine this UA was created on. A local user account does NOT have any network access credential in an Active Directory environment.

    Domain User Account - is a user account you can use in a Windows NT/2000 Domain Environment. This user account is set up on the domain controller(s). The user can log on to any network client authorized by domain controllers (means you have to add the machine to the domain prior to use domain accounts on them) with the same userID and password and have different settings (desktop wallpaper, start menu, default dialup connection...) for each client machine he logs on.

    Roaming User Profile - As we said before this is a particular Domain UA. Works the same way as any domain user account, but the user will always have the same settings regardless the network client he logs on to. At each logon the client machine will download user profile and settings from the server and upload back any changes at each logoff.

    Mandatory User Account - This is a slightly different Roaming UA. The only difference from a Roaming UA is that the user can't change any setting of the profile. He can do whatever he wants during each session (delete desktop icons, change screensaver, create new network connections...), but the server will ignore any changes and after each logoff the domain controller will restore the profile state back as the initial administrative setup.

    Guest Account - The guest account have the lowest privileges both locally and on the network. Basically he can't do mostly anything unless explicitly granted by administrators. The Guest Account has no login password and is disabled by default for security reasons.

    Please note! A Domain UA does not need correspondance of a local UA on each client machine.
    Suppose you have a user named John in a domain named *MyDomain*.
    A local UA would store the user profile files in the folder: *C:\Documents and Settings\John* .
    A domain UA would store those files in the folder: *C:\Documents and Settings\John.MyDomain*. This means you can use both a local *John* profile and a domain *john* profile on the same machine, but they will always be two distinct *john* with different SIDs (Security ID) even if they have the same password. Logically only the domain UA will receive network authorizations and Active Directory policies (local *john* would always have network access denied). Each *john* login will be treated separately and read information from its corresponding *documents and settings* folder in case you use that login in the domain or locally.
    If you have a local and a domain *john* UA using the same password, this would most likely cause security problems in reading Active Directory permissions from domain controllers. So I advice you to avoid setting up local UA with a username equal to any domain UA.
    Once again, if you have a *john* domain UA and you want him to log on any network client then the only thing you need is a proper domain UA, you don't need a corresponding local UA... means no further configuration on the client, just login to the domain from the client... AD will do the rest.

    This was to say that you will never find the import utility you were looking for because of these fundamental reasons:
    1. Active Directory security principals are based on the fact that the domain accounting policies reside ONLY on doamin controllers.
    2. Such an utility would be useless because any domain machine is able to read all accounts from domain controllers.
    3. Duplicating UA from domain to local would be an unuseful administrative overhead. Active Directory gives you the powerful benefit of having a single administration point for accounting management.
    4. There is no AD database on the laptop clients. Clients are only able to read AD from domain controllers SYSVOL share (the only place where AD database resides).

    Now the specific case.
    If you manage the school network as a domain environment and need to grant the same limited access to each of the students then the best thing to do is to set up a Mandatory User Profile named *Student*, a single one for all students. As said before a mandatory UA will prevent students from changing any of the settings (including the login password) you define initially and the domain authentication will save you from setting up 350 different local UAs on any classroom client machine. Then use NTFS permission and eventually Group Policy Objects to further restrict the students' use of the network/domain/computer.
    If you need help on assigning a mandatory User Profile, check;en-us;q323368

    Sorry if I talked that long but I was not sure you knew precisely what I was talking about.
    Good luck!