This week's article takes a look at both Configuring and Troubleshooting the Desktop Environment as well as Implementing, Monitoring and Troubleshooting Security. This includes a look at user profiles, windows installer packages, desktop settings, accessibility services, policies, managing domain accounts, and more.
by Dan DiNicolo
Welcome to article number 6 in my 70-240 in 15 minutes a week series. This week's article takes a look at both Configuring and Troubleshooting the Desktop Environment as well as Implementing, Monitoring and Troubleshooting Security. This includes a look at user profiles, windows installer packages, desktop settings, accessibility services, policies, managing domain accounts, and more. This article is a tiny bit longer than usual at 6 pages - a good deal, since we're combining two major topic areas (hey, it could have been
10 pages!). Note that some of the topics discussed in this article, such as Group Policy, are only meant as an overview since you are not required to know all the details for the Professional portion of the exam. The full-blown versions of these topics will be covered in future parts of the series in much greater depth - so worry not!
The material that this article will cover includes:
- User Profiles and Logon Scripts
- Multiple Language and Location Support
- Windows Installer Packages
- Desktop Environment and Accessibility Options
- Managing Domain Users, Groups, and Authentication
Windows 2000 maintains a user's desktop configuration and environment settings in what is called a user profile. Settings found in a user profile include things like the wallpaper the user has set, the placement of the icons on their desktop, mouse settings and so forth. In Windows 2000, a user's profile can be found under the folder
Documents and Settings, in a folder that maps to their user name, as shown below:
If the system has been upgraded from NT 4, however, profiles will still be found under the
%systemroot%\profiles folder. By default, all user profiles are local. That means that when a user logs on to a system for the first time, they receive a new profile, and any changes they make are stored on that machine only. By contrast, you can also store user profiles on a server such that they follow users as they move from machine to machine. These are referred to as roaming profiles. When a user logs off a system, their settings (including any changes they have made) are saved back to the central server. Note that certain folders, such as My Pictures and My Documents, are part of the user profile. As such, if you are using roaming profiles, and a user has a number of large files in these folders, it can cause significant network disruption. However, Windows 2000 does keep a locally cached copy of roaming profiles on a system. As such, if a user has a large roaming profile and usually uses the same machine, only the changes are copied back and forth, not the entire profile every time they log on.
Roaming profiles are configured in the properties of a user account (on the Profile tab), by providing a UNC path to where the profile is stored such as \\server2\profiles\dan. In order to make things simpler, consider setting user accounts up for roaming profiles by using the
%username% variable instead of the actual user name. This will automatically create a profile location on the server with the same name as that of the user (if you do this, only the administrator and user will have full control over the profile by default if the target volume is formatted NTFS). If you want to take an existing local profile and change it to roaming, you must set the properties on the user account as mentioned above, as well as copy the local profile to the server using the Copy To button on the Profiles tab in the System Program as shown below:
As in NT 4, you can still make a profile mandatory (unchangeable) by renaming the Ntuser.dat file in the profile to
Windows 2000 still also allows you to set up a logon script, which will execute when a user logs on. This can be used to do things such as map a network drive, map to printers, and so forth. Logon script properties are set on the properties of a user account, as show below:
Note that you need only provide the name of the script. The script itself should be stored in the
Sysvol\domain\scripts folder on a domain controller. As in NT 4.0, you can also provide a home directory location, which can be either on the local machine or the network.
Multiple Language and Location Support
Windows 2000 is capable of supporting many different languages, and includes support for different locations. Language properties are set using General tab of the Regional Options applet in Control Panel, as shown below.
Do not confuse Language settings (the lower part of the screen above) with Locale settings (which will be discussed in a moment). Additional languages allow you to read and write documents in multiple languages. They do not change the interface language of the OS. Note that only an Administrator can install additional languages, and a reboot is required.
Languages are different than Locales, which allow you to control settings about a language. This includes properties such as currency symbols, format of dates, numbers, and so forth. The two types of locales are user locales and input locales. User locales maintain settings on a per-user basis, such as currency symbols, date formats, etc. Input locales control the keyboard layout, and allow you to switch between layouts on the fly, via an icon in the system tray (as shown below). The input locales available will depend upon the languages that have been installed.
Just to confuse things, Windows 2000 is also available in a Multilanguage version, or a version that allows you to change the interface language from one language to another. For example, if you were supporting users who speak Spanish, they would be using the Spanish interface, but for support purposes, you could change the interface language to English. Each users profile would store their interface language preference.
Windows Installer Packages
Windows 2000 includes a new service called the Windows Installer Service that is responsible for managing the installation and removal of applications. The Windows Installer service works in conjunction with a new application package format, the
.msi file. An msi file is a package that contains all the necessary instructions to install an application on a computer. This includes which registry entries should be added or changed, which files should be copied to which locations, which shortcuts should be created, and so forth. This technology can allow an application to be deployed without any user intervention whatsoever. Note that the msi file doesn't actually contain all of the files to be deployed. Instead, it contains the instructions for how the application is to be deployed. Benefits of the msi and Windows Installer method of installing software include self-healing and resilience of applications. That is, if a user were to accidentally delete or remove files associated with a deployed application, the application will go back to it's installation source (assuming it is available), and will automatically fix itself.
Many applications are now distributed with setup.msi files. However, you can also create your own msi packages using a variety of software packages. The Windows 2000 CD provides a Veritas repackaging application, WinInstall LE, which can be used to create msi-based application packages.
If you have Windows 2000 Active Directory installed, packages can be distributed via group policy to either users or computers. Although I'll reserve going into all the details until the Server portion of the series, here are the basic details for now:
- Packages distributed via group policy (using Active Directory) do not need elevated privileged to be installed. As such, a regular user can invoke the installation of a package without needing to be an administrator, for example.
- Packages can be assigned or published to users or computers via group policy. If assigned to a computer, the package is installed when the computer reboots. If assigned to a user, the package is not installed, but appears to be (as a shortcut on the start menu). When the user clicks the shortcut, the package is installed. If published to a user, the software is available to be installed via Add/Remove programs (or automatically when the user clicks on a file extension associated with that program). Packages cannot be published to a computer.
- If a program cannot be repackaged, it can still be deployed via group policy with a
.zap file. A zap file is a text file that contains instructions on how to install an application. A user needs elevated privileges to install an application deployed with a zap file. A zap file can only be used to publish an application to a user. Want more details on zap
Desktop Environment and Accessibility Options
Windows 2000 contains a number of small changes to the desktop environment in terms of both interaction and accessibility features. The desktop settings that can be controlled by a user include settings relating to the keyboard, mouse, display, sound, toolbars, and the start menu. These settings are all stored as part of the user's profile, and are outlined individually below.
Keyboard - The keyboard applet in Control Panel controls settings relating to keyboard functionality including cursor blink rate, character repeat rate and delay, as well as another place from which to control input locales, as discussed earlier.
Mouse - Allows you to control hand-orientation of the mouse, as well as pointer, motion, double-click speed, and hardware.
Display - Allows configuration of the background display, screen savers, window appearance, active desktop, effects (such as fade or scroll) as well as color configuration and screen area resolution.
Sounds and Multimedia - Allows configuration of system sounds, volume, and schemes.
Toolbars - Windows 2000 allows you to show additional toolbars from the taskbar at the bottom of the screen. Right-click the taskbar and choose the toolbars option to allow you to view a number of different toolbars including links, an address bar, a desktop bar, the quick-launch bar (onto which you can drag shortcuts to programs you use most often), and others that you define.
Start Menu - The Start menu is Windows 2000 can be changed by dragging items on or off of it. Furthermore, the Start Menu can 'learn' from you, and will display only those items that you use most frequently. This feature is called personalized menus, and can be turned off. The configuration of the Start menu is handled via the Taskbar and Start menu program, found under the Settings option on the Start menu. This allows advanced menu configuration, including the ability to show or hide the Administrative tools, as well as the ability to expand shortcuts such as Control Panel, in order to be able to also view the tools within from the menu. Examples of these settings are shown below.
Windows 2000 also supports a variety of accessibility options for users with visual, hearing, and motion impairments. These settings can be controlled from a two different places - the Accessibility menu and Control Panel. The Accessibility Options applet in Control Panel allows you to set the options relating to the keyboard, sound, display, and mouse. Each is looked at below, according to tab:
Keyboard - Contains options for setting Sticky keys (where you can press combinations of keys, such as CTRL+ALT+DEL, one key at a time),
Filter Keys (which will ignore brief or repeated keystrokes), and
Toggle Keys (which provides a tone when you hit CapsLock, NumLock or ScrollLock).
Sounds - Contains options for setting Sound Sentry (which will display a box onscreen when the system makes a sound) and
Show Sounds (which will have programs display captions for any speech or sounds made).
Display - Contains an option to display the screen fonts and colors in
High Contrast, making things easier to read.
Mouse - Contains an option to set Mouse Keys, which allows your keyboard's numeric keypad to control the pointer.
General - The General tab contains settings that allow you to control accessibility features, such as turning off features after 5 minutes of not being used, or making the settings applicable to all users on a system. The General tab is shown below
Windows 2000 also provides a few new tools on the Accessibility menu, as outlined below:
Narrator - This tool actually speaks the contents of things like menu items, text, and so forth.
On-Screen Keyboard - This tool displays the keyboard on-screen, allowing users to press buttons with the mouse instead of the physical keyboard.
Magnifier - This tool actually magnifies part of the screen by splitting it into two panes. The upper pane displays a magnified version of whatever the mouse is currently pointing at in the lower pane.
Accessibility Wizard - Essentially, this tool allows you to create a custom accessibility profile for a user, using any of the accessibility options discussed. These options can also be saved to an .acw file, and then be distributed to other uses that need a similar configuration. Note that by default, the saved acw file will have an associated access control list that gives the user who created it and the administrator access. If you want any other users to use this acw file, you will need to modify the permissions associated with it.
Policies form the basis on environment and security configuration in Windows 2000. In very broad terms, two types of policies exist - Local Policy (which is set on an individual computer) and Group Policy (which can be applied to multiple computers and users according to settings in Active Directory). Without Active Directory, only Local Policies can be applied. First well look at Local Policies, followed by an introduction to Group Policy.
Local security policy controls security-related settings on an individual Windows 2000 system. Settings found in the Local Security Settings tool relate to three major areas - Account Policy, Local Policy, and Public Key Policy, as shown below:
Account Policies control settings such as password policy (password uniqueness, age, etc) and account lockout policy (lockout threshold, duration, etc) for local accounts. That is, these settings only apply to accounts contained within the systems Security Accounts manager (SAM) database, and not to domain accounts.
Local Policies contains settings relating to the Audit policy on the local system, the assignment of user rights, and security options. Audit Policy includes options for types of events you wish to audit, such a file and object access over this particular system. User Rights assignment is where you would give users or groups rights to perform system tasks, such as the right to change system time, or the right to back up files and folders. Note that this is different that in NT 4.0, where rights were given using the User Manager tool. The Security Options section of Local Policies allows you to control security-sensitive settings on the local machine, such as disabling the Ctrl+Alt+Del requirement for logon, clearing the pagefile on shutdown, and so forth. An example on some user rights settings is shown below:
Public Key Policies in the Local Security Settings tool allow you to set the EFS recovery agent, which by default will be the local administrator account.
Although local policy settings give you a strong degree of control, they are still fairly inflexible in that they must be configured locally on each machine. Note that it is possible to export policy settings to a file, and then import those local settings on to another system. Windows 2000 also includes a snap-in called Security Configuration and Analysis. This tool allows you to save policy settings to a database file, and then compare changes to security settings against this database. It is a useful tool in determining the impact that a change to a policy setting will have. This tool also allows you to save the database to a template file
(.inf file), which can then be applied to other systems. For more details about the Security Configuration and Analysis tool,
In an Active Directory environment, policy settings are more easily applied using Group Policy. Group Policy is a more effective tool because it allows you to centralize the application of policy. Group Policies can be applied at 3 different levels in Active Directory: site, domain, and organizational unit (OU). Group policies allow you to configure all kinds of settings relating to the user and computer environment, such as removing the Run command or forcing certain wallpaper. They also include the security settings we discussed in Local policy. A deeper look at setting areas will be looked at in the Server portion of the series.
Although we haven't yet really discussed Active Directory in the series, a brief overview will suffice for now. A site is a physical location in Active Directory. Any policies applied to a site will apply to all users in that site, regardless of the domain or OU they are a part of. A domain is still very similar to what you remember from NT 4. Any policy applied to a domain will affect all users and computers in the domain. Finally, an Organizational Unit, or OU, is a smaller container within a domain that represents breakdown for the purpose of administration or organization of objects (such as users and computers). Any group policy applied to an OU will affect users in that OU, as well as any sub-OUs (since OUs can be nested).
Since Group Policy can be set at different levels, it is possible that settings at one level (like site) could conflict with settings at another (like OU). As such, it is important to understand the order in which group policy gets processed. The order is:
Local Policy - Site - Domain - OU
What that means is very important, and you must understand it. Imagine you are a member of an OU called Sales in a site called Tallinn. All group policy settings merge together. That is, if a Tallinn site-level policy says you get green wallpaper, and a Sales OU-level policy removes the Run command, you will end up with green wallpaper and no Run command. However, if there is a conflict, the settings applied later will take precedence. Imaging the Tallinn site policy removed the Run command, and the Sales OU policy enabled it - you would end up having the Run command, since OU policy is applied after the site policy. Note that logging off and back on isn't necessary in order to obtain the vast majority of group policy settings in Windows 2000. Group policy settings are automatically updated on the client system every 90 minutes by default (with a 30 minute offset). There is much more to Group Policy than just what has been discussed here - a more detailed look at group policy will follow in the Server portion of the series.
Managing Domain Users and Groups
Local users and groups exist only in the SAM of a local Windows 2000 system, and can only be used for access on the system on which they exist. As such, local accounts are not practical for use in a large environment, due to their distributed administrative nature. As such, most companies have a domain, which of course centralizes user and group administration, as well as the authentication function, on Windows 2000 Servers acting as domain controllers. Domain controllers do not have a local SAM, but instead share and replicate the Active Directory database, where user and group objects (amongst other things) exist. In this section we'll take a look at a number of features of accounts that still exist, but some that are different than in NT 4.
First of all, every account in Active Directory is an object, and objects can have properties. Examples of properties include things like a first name, last name, password, phone number, and so forth. There are many more properties associated with a domain user account than a local user account, as shown below (local account properties on left, domain on right):
In very basic terms, local accounts are still very much like accounts in NT 4, while Windows 2000 domain accounts potentially have many more properties associated with them. Domain accounts (users, groups, computers, etc) are set up using the Active Directory Users and Computers tool.
Some basic things you should know about user and group accounts in a domain environment in Windows 2000:
- User accounts and security group accounts still have a SID (security identifier) associated with them. Renaming an account retains the SID, and may be a good idea if one person is the company replaces another, for the purpose of resource access.
- If you delete a user account, you also delete the associated SID. Creating another account with the same name will produce a new SID, and therefore an entirely new account.
- If a person is going on a leave of absence, you can still disable an account.
- The domain administrator and guest accounts cannot be deleted, but can (and probably should) be renamed. The Guest account is disabled by default.
- You can still copy user domain user accounts, as in NT 4. Note that only generic items will be copied, such as group membership and so forth. More specific properties, such as a user's home address, will not be copied. Copying account is most useful if you create a template account for different types of users. (Note that if you create a template account and disable it, all accounts copied from this template will also be disabled until you specifically enable them). Note also that if you copy an account called Mike, for example, and the copy is called Bob, access permissions to resources associated directly to the Mike account are NOT copied to Bob.
- When dealing with group accounts, you can easily find out what other groups this group is a part of by checking the Member Of property tab. The Members tab shows other users and groups who are part of this group.
Note that Windows 2000 supports three different types of groups: Domain Local, Global, and Universal. Groups can also be nested in Windows 2000, meaning a group can be part of another group (potentially - there are rules). Note that group nesting and Universal groups are only supported in Native mode (a mode where all domain controllers are running Windows 2000), and not in Mixed mode (where you might still have NT 4.0 BDCs present). This will be covered in greater detail later in the series.
In order for a user to use a Windows 2000 Professional system, they must be authenticated. Authentication occurs when a user provides a valid username and password combination for the system or domain they are logging into. If logging into a Windows 2000 system locally, the user must provide a username and password from the local SAM database on that system. When logging on to a domain, a valid domain username, password and domain name (from the drop-down list) must be provided. Alternatively, you can also log in with something called a User Principal Name (UPN), which looks like an email address in the format email@example.com. If a UPN is provided, the user does not need to choose a domain name from the drop-down box (this will actually be disabled automatically when a UPN is used). When a user is logging on by sitting in front of a system, this is referred to as an interactive logon. In the same manner as NT 4, if you want a system to lock automatically after being idle for a period of time, set up a screensaver - the system will lock automatically after the interval you specify.
One last possibility that you should be aware of in Windows 2000 is the ability to automate the logon process. That is, you can set Windows 2000 up such that is does not require that a user provide a username and password to log in. Instead, the system will login automatically using the credentials you supply. You can control this behavior (which is obviously not recommended on systems that require security, but may be useful on, say, a kiosk system) by using the Users and Passwords applet in Control panel. You must specify the user account that the automated logon should use. Note that authentication is still taking place, but everyone is automatically being authenticated as the same user.
Well, that takes care of yet another week in the series. Yes, this one was a little longer than usual, but we're still ahead since we covered two topics this time instead of one. My next article will cover Network Protocols and Services, as well as a look at something you absolutely must be familiar with in order to have any success on the exam. I'll let that be a secret for now - no need to get you worked up and worried too soon! If you just can't wait, however, you may want to
check out my website, where I've just made a new type of practice exam available, which directly corresponds to next week's mystery topic. Once again, please feel free to
email me with any questions or feedback you may have about the series; I look forward to hearing from you. Also, I would appreciate any feedback you might have about how you think my website might be made a more valuable resource. What would you like to see? I'm listening...
In the meantime, good luck with your studies this week.