CSED 431 Week 9 -- March 29



Windows Server 2008

Laptop3 problem
Somehow not only was winser08 acting as a DHCP server, but it was also acting as a DHCP relay.

Fixing this particular problem did not make everything work (of course). I ended up replacing winser.vdi from another machine.

Domains

Just what is a domain?

First, a Domain Controller is simply the host for the so-called Active Directory database. At its simplest form, this is a list of user records indicating who is allowed to log on.

Domain membership means using that AD database for domain logons, so that users need to change their password only once to change it domain-wide.

Domain membership also means that computers agree to accept system settings as enforced through the domain Group Policy. This is basically a collection of system rules (most of them enforced on individual machines via registry settings), plus a mechanism for enforcing these on hierarchical sets ("organizational units") of users and sets of computers.

Note, however, that Group Policy settings are ultimately enforced by the individual member computers, on their own.

For a given policy setting, Group Policy usually allows three options:
As a rule, domains work best when all the member computers are similar: the same OS, and very similar software configuration.

Also, once a computer has joined a domain, it may not function well off the domain, so laptops are often a significant problem. Security settings may be enforced, for example, that have the effect of requiring domain access, even when the machine is away from the domain.

Roaming profiles

A database for domain logons can be as simple as a list of ⟨username,password⟩ pairs, but generally also consists of each user's full profile: the My Documents folder, the Desktop, and the ntuser.dat registry file. (Also the folders UserData, Cookies, and Start Menu.) I will call My Documents, etc the personal folders, and ntuser.dat the registry profile.

Note that in a typical office setting, where each user is assigned a particular machine more or less permanently, roaming profiles are not needed. However, in a lab setting, it is very important that profiles either be roaming or be read-only (the microsoft term for the latter is "mandatory").

In a classic roaming profile, these are downloaded to the user's machine on logon, and then uploaded on exit. This is a slow cumbersome process. For a list of further complaints, see http://en.wikipedia.org/wiki/Roaming_user_profile. Perhaps the most serious problem occurs when a user logs on to two machines simultaneously and makes conflicting settings, or else the user logs off one machine and logs on to another before the first machine's upload has completed.

A better strategy for the data folders (My Documents and Desktop) is redirection: having these folders exist on the server, but appear to exist in their usual place. This means network bandwidth is consumed for each access, but that his normally not a serious problem.

An entirely different strategy is to, at logon, mount the user's personal server folder, say \\diskserv\homes\pld, as drive U: (or any other letter). This amounts to the same thing as redirection except that a different name is used. (This kind of drive mounting serves as perhaps the most significant application of logon scripts). The mylogon applet (below) also supports this kind of scripting.

As for the registry profile, a common problem is that the individual ntuser.dat files grow too large, and downloading them begins to take an appreciable amount of time. An alternative approach is to use a mandatory profile: a fixed read-only profile. Users may make changes to their workstation environment after they log on, but these changes are lost upon logoff. Mandatory profiles are still cached, and in the non-domain setting mandatory profiles are copied for each user, but the copies are not further changed.

It might be possible to use logon/logoff scripts to copy a standard registry profile (ntuser.dat) and then delete it on exit, but this is tricky: you can only copy something into ntuser.dat before the hive is loaded, and you can only delete the file after the hive is unloaded. If your logon/logoff script isn't synchronized with respect to registry loading/unloading, you may be out of luck.

Note that ntuser.dat for XP-and-earlier is now known as a "v1 profile"; vista/7/server2008 profiles are now known as "v2 profiles".

Note also that the registry profile contains all sorts of software settings. If a user uses version 2 of a software package on one machine, and then logs on to another machine with version 3-pro installed and starts the software, the software will see version-2 settings in the registry. The situation may be much worse if it is done in the other direction; version 2 may be completely unable to cope with v3-pro settings. Note that this has nothing to do with v2 or v3pro data-file formats.

Ideally, the software handles this by including the version number in the registry "key path", eg
    ...\...\foosoft\timewaster\2.0.3.a60844\pro

Mandatory profiles:

http://support.microsoft.com/kb/307800

Basically, profiles are made mandatory by renaming ntuser.dat to ntuser.man.

In the non-domain context, you can use the Admin Tools => Computer Mgmt => System Tools => Local Users & Groups => Users => Properties => Profile to spell out a profile path (either locally or on a server). Local paths being with something like C:\; a typical server path is \\servname\profiledir\%username%.

Note that %username% is a general shell variable in Windows that always represents a standin for the actual username.

Somewhat peculiarly, when you create a mandatory profile for a user, Windows then makes an individual copy of that profile for that user! It's still a mandatory profile, but the benefit of having multiple users share the same read-only profile file is lost.

Default profiles

How do you set the initial default configuration?

Mylogon

At http://mylogon.net, there is a different strategy. A small applet in effect replaces the winlogon.exe program. A user provides a username/password pair, and these are validated against a server. If logon succeeds, a script runs that sets up various file shares.

Demos

Logon/logoff of user sally/sally
creating OUs and GPOs
profile tab for local users and for domain users
problems accessing Sally's files on the server


Lab

Log into winser08. It should now be a domain controller.

1. Create an Organizational Unit within the users, called Students or StudentsOU. (OUs are created with Group Policy Management. Right-click on the domain csed.cs.luc.edu, and click "New Organizational Unit".)

2. Create a Group Policy Object for the StudentsOU, called StudentsGPO. (GPOs are created with Group Policy Management. Be sure your GPO links to your OU.)

3. Make some Students settings in the GPO, eg folder options, or classic start menu, or desktop bckground [?].

4. Enable folder redirection for Documents, and include XP users. I created a folder C:\homes Note that its UNC name (the name by which it will be seen by clients) is \\winser08\homes. If you use "basic" redirection, you only need to specify this "top-level" folder; the individual profiles will then go into, say, \\winser08\homes\%username%, where %username% is a general-purpose standin for the username of whoever is logging in.

5. Anticipating profile sharing as well, also create a folder c:\profiles

5.1 Set up the folders above for read-write sharing by everyone.

6. Add some users using the domain controller. Fill in the profile tab of the user properties to hold \\winser08\profiles\%username%.

7. Move your users to the StudentsOU (or just create the user there in the first place).

8. Make sure win1 and win2 are domain members.

9. Log in to win1 using one of your user accounts. Change some profile setting. Create a file in My Documents. Log out and log in again. Are your settings still there?

10. Now log out and log into win2 using the same account. Are the files the same? The settings?

I had, well, less trouble than expected getting this to work, but then deleting my first attempt proved nearly impossible! Windows would not let me delete c:\homes because it contained subfolders owned by others, and wouldn't let me change ownership either. I finally ended up finding and using the following pair of commands, in an Administrator shell:
    takeown /f directory_name /r /d y
    icacls directory_name /grant administrator:F /t
To get a shell running as administrator, try
    runas /user:Administrator powershell      (or cmd)