Mike here again. This is the first of a two part series that originally published on the Group Policy Team blog - updated for Windows Server 2008.

I wanted to bring to your attention some new policy settings for Windows Server 2008 and Windows Vista. The Windows Logon Options policy settings are located under both the Computer and User Configurations\Policies\Administrative Templates\Windows Components\Windows Logon Options. This policy category has six policy settings, equally divided between user and computer configurations. These policy settings apply to computers running and users logging onto Windows Server 2008 and Windows Vista. Earlier versions of Windows will ignore most of these policy settings.

NOTE: Read the explain text of each policy setting before you combine these policy settings with earlier policy setting in a single Group Policy object.

Figure 1- Windows Logon Options policy settings

I’ll start with highlighting two of the three policy settings under the Computer Configuration. The first of these is the Display information about earlier logons during user logon. When enabled, Windows displays a message after the user logs on. The message contains the date and time of the last successful logon; the date and time of the last unsuccessful logon; and the number of unsuccessful logons since the last successful logons by that user. The user must then acknowledge the message before Windows presents the user desktop.

Figure 2- Display Information about earlier logon result

I know, this sounds like one of those annoying logon prompts that users click through—perhaps. However, I see this as another step in securing Windows on the workstation and the network. Most users know when they logged on last. Additionally, they know when they have typed their password wrong multiple times. Enabling this policy provides this information to users at each logon. Users can then evaluate this information with their own logon patterns to determine if there has been an attempt to compromise their account. And, you can use this policy setting to assist with troubleshooting account lockout issues. It's certainly useful for servers, where only administrators should have ever been logging on through the console or Terminal sessions.

NOTE: This policy setting requires the logging on user account to be a user account from a Windows Server 2008 functional domain. Users logging on with user accounts stored in domains functioning at Windows Server 2003, Windows 2000 native, or mixed mode encounter an error message stating Windows could not locate the account information and prevents the user from logging on to the domain.

The other valuable policy setting in this category is the Report when logon server was not available during user logon. Windows displays a notification to the user explaining they have logged on using cached credentials because the logon server was not available. Enabling this policy could expedite the reporting of logon problems. And, as with the other policy, serves as an excellent way to further troubleshoot logon problems.

Figure 3- Results from Report when logon server not available

Stay on the look out for some of the new policy settings in Windows Vista and 2008. Sometimes, enabling a policy ahead of time can help you troubleshoot later.

-Mike Stephens

Hello again - Bob Drake here. Today I will be talking about a particular behavior with account lockouts that might be seen with the introduction of “Read-Only Domain Controllers” (RODC's) in Windows Server 2008. Windows 2008 RODC’s are domain controllers that can authenticate users and computers, but hold a read-only copy of Active Directory. This means that any changes (or writes) made to Active Directory must then be forwarded to a writable domain controller. Traditionally, account lockouts happen for many different reasons; with RODC’s there are a few added layers of potential issues that can complicate the efforts of resolving lockouts.

The first step in understanding account lockouts is to thoroughly read through our TechNet whitepaper “Windows Server 2003 Security Guide”. In this guide, Microsoft points out the recommended settings to have a secure lockout policy. Unfortunately many customer implementations are configured with settings that cause “false lockouts”. The information suggested in this document is applicable to all Active Directory versions, not just 2003. False lockouts are accounts that lock out due to user error rather than application error. For instance, the recommended “lockout threshold” is to be set at 10 or higher:

“Account lockout threshold setting value to 50 for the Legacy Client and Enterprise Client environments, which should provide adequate security and acceptable usability. This value will prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack as described earlier. However, this guide recommends that you configure this policy setting value to 10 for Specialized Security - Limited Functionality environments.”

Traditionally floods of false account lockouts are resolved by installing the “account lockout tools” and following the steps outlined in the TechNet article which describes how to use the tools.

** Special note here: Do NOT install the Account Lockout DLL on an Exchange server since it may prevent the Exchange store from starting **

Once the tools are installed you can view the properties of the account password information directly on the user object in Active Directory Users and Computers:

As seen it matches what the default domain policy is set to:

In normal 2003 environments users authenticate with a local domain controller within their site. With the introduction of RODC’s, the authentication is a little different. There is a new password feature built into Windows Server 2008 called “Password Replication Policies”. The particular thing to point out from this article is:

“An administrator can, for example, specify in advance any accounts that an RODC will cache. This way, the RODC can authenticate those accounts, even if the WAN link to the hub site is offline.”

• If an account password has been allowed to be cached, then they can authenticate even if the WAN link is down.
• If an account password has not been allowed to be cached, then they will not authenticate if the WAN link is down.

I recommend extensive consideration and planning to determine the best solution for which accounts will be cached with considerations given to WAN links and reliability. Pay particular attention to the three solutions:

• No accounts cached
• Most accounts cached
• Few accounts cached

When a user logs into a computer located in a site where there is an RODC and the user’s password is not cached, the RODC in turn will make a request to a writable Windows Server 2008 domain controller (For more information on RODC’s and how they differ from writable domain controllers). If this writable DC is out of site and possibly over a WAN link, this could become a bandwidth issue, and potentially cause logon failures if it is an unreliable link. See the section “Password Replication Policy in operation . If the users password is allowed to be cached, after authenticating the user, the RODC with then requests a password replication and pulls the password into cache. There are a couple of cool methods on pre-populating the password cache:

• Method 1: Open Active Directory Users and Computers from a writable domain controller, right click the RODC and go to properties. Select the “Password Replication Policy” tab then the advanced button. Once the next box opens, user accounts can be added by using the “Prepopulate Passwords” button and selecting the users from Active Directory:

• Method 2: Using the “Repadmin” utility from the support tools (this tool is built into Windows Server 2008 but can be downloaded for Windows Server 2003 here), and run the following syntax:

repadmin /rodcpwdrepl [DSA_List] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished Name> <User2 Distinguished Name> …]

Success!

Cool Tip: If you have set up an RODC or you are taking over an RODC implementation and want to manage the users that have been authenticated to it with as little administration as possible you can use the “Repadmin” command to make your life easier:

Repadmin /prp move <rodc> <group>

The move command will send all the security principals from the “Authenticated to” list to the specified group that you name. If the group that you name does not exist, it will create the group on the fly, and also adds the group to the “Allowed List”… check it out:

Notice that it asked to move all the security principals from the “auth2” list to the group I created “2008authlist” and created the group for me. This allows me to keep track of who authenticated in 2008, and manage that group automagically by sending all the users who authenticated to my RODC to a security group that I can control. From here I can run an LDIFDE command against the new security group and output its contents for auditing purposes:

Now getting to the account lockout portion and what administrators may run into. Let’s take a look at the following potential scenario:

• User who has not been able to cache their password since a WAN link was down (IE: an executive visiting an offsite branch location)
• The account lockout threshold is set at “3” on the Default Domain Policy.

NOTE: I went with the account lockout threshold set at three (3) to show that when the threshold is set lower than the recommended setting of 10, there is a potential for false lockouts to occur. In this scenario the WAN link goes down, and the user tries their password more than 3 times incorrectly, causing the account to lock out. The real problem was not the threshold but the WAN link, but since the threshold was set too low, another issue happened.

• The WAN link from the remote site goes down and the only available domain controller is the RODC

No user passwords are cached on the 2008 Core RODC as seen:

User “Bob Drake” logs attempts to log into the RODC when the WAN link is down and gets the following:

First problem: Since the RODC needs a writable Windows Server 2008 Domain Controller, it fails the authentication and gives the error that the domain is not available.

Second Problem: Since we chose not to cache the user’s password in advance the user fails to log in.

To address the issues, and administrator changes the “Password Replication Policy”, allows for the user account password to be cached and resolves the broken WAN link:

So the user “Bob Drake” logs in again successfully and the password is cached:

Now going back to the scenario, let’s say that the WAN link goes down (remember our account lockout threshold was set at 3) and the user types his password wrong three times causing his account to be locked out on the RODC. Note that it does not show in the GUI on any of the domain controllers:

2008 standard domain controller:

2008 RODC:

From the users view of his account that is locked out:

If we connect to the RODC using ADSIEDIT and take a look at two accounts side by side, we can see that the user account “Bob Drake” is locked out even though normal tools do not show it:

Note: The “LockoutTime” is stored in NT System Time format. To convert to a readable format you can use the w32tm command (w32tm /ntte):

When this occurs, there is no way to “unlock” the user’s account using normal methods like Active Directory Users and Computers. This is a unique case now since the user will be complaining that his account is locked out, but the administrators that look at the account do not see it as locked account. Other users continue to work (as long as the passwords were cached) providing they have not attempted three bad passwords making it appear that there is no other issue expect the account authentication lockout. A domain administrator would look at this and may be stumped on how to unlock the account.

To get the account unlocked the WAN needs to be restored, which will allow for the user to authenticate again without doing anything else. Under normal account lockout methodology, the user’s bad password count would normally get replicated to the other domain controllers in the environment, but not the case here. Simply restoring the WAN link will then reset the bad password attempt to zero (0) and the account will no longer be locked out, allowing the user to attempt login again.

In a situation like this where a company has implemented a RODC in a branch site, has a restrictive password policy set at the domain level, or an unreliable WAN link - they might want to consider creating an alternate “Fine Grain Password Policy”. This will allow a policy to be set that has a higher account lockout threshold than the default domain policy as well as a higher precedence. This way, when users at the branch office mistype their password more than three times, it will not lock the account out like the rest of the domain (or at least till they hit the higher threshold).

New OU Fine Grain Password Policy with higher threshold and precedence:

To conclude, I highly recommend reading through the documentation about implementing Read-Only Domain Controllers (and possibly how site topologies work). If you know you have an unreliable WAN link, or there are strict password policies set at a domain level, you may want to reconsider the implementation of an RODC to accommodate your environment and make the RODC transition go smoothly.

-Bob Drake

Hi, Ned here again. Today I am going to explain the inner workings of DFSR pre-staging in Windows Server 2003 R2, debunk some myths, and hand out some best practices. Let’s get started.

To begin, this is the last time I will say ‘pre-staging’. While the term is commonly used, it’s a bit confusing once you start mixing in terminology like the Staging directories. So from here in I will refer to this as ‘pre-seeding’ and hope that it enters your vernacular.

Pre-seeding is the act of getting a recent copy of replicated data to a new DFSR downstream node before you add that server to the Replicated Folder content set. This means that we can minimize the amount of data we transfer over the wire during the initial sync process and hopefully have that downstream server be available much quicker than simply letting DFSR copy all the files in their entirety over potentially latent network links. Administrators typically do this with NTBACKUP or ROBOCOPY.

How Initial Sync works

Before we can start pre-seeding, we need to understand how this initial sync system works under the covers. The diagram below is grossly simplified, but gets across the gist of the process:

Take a long look here and tell me if you can see a performance pitfall for pre-seeding. Give up? In step 6 on the upstream server, files need to be added to the staging directory before the downstream server can decide if it needs the whole file, portions of a file, or no file (because they are identical between servers). Even if both servers have identical copies, the staging process must cycle through on the upstream server in order to decide what portions of the file to send. So while very little data will be on the wire when all is said and done, there is some inherent churn time upstream while we decide how to give the downstream server what it needs, and it ends up meaning that initial sync might take longer than expected on the first partner. So how can we improve this?

How initial sync works with pre-seeding

First let’s take a look at how things will work on our third and all subsequent DFSR members in a Replication Group:

Since the staging directory upstream is already packed full of files, a big step is skipped for much of the process and the servers can concentrate on actually moving data or file hashes around. This means things go much faster (keeping in mind that the staging directory is a cache and is finite; the longer one waits, the more likely changes are to push out previously staged data). In one repro I did for this post, I found these results in my virtual server environment :

Environment:

• Three Windows Server 2003 Enterprise R2 SP2 servers running in Virtual Server 2005 VM’s on a private virtual network.
• 4GB staging (the default).
• 5.7GB data on a separate volume on upstream server.
• To determine replication time, I measured the difference between DFSR Event Log event 4102 and 4104 (like so):

Testing results:

• New Replication Group with no pre-staging
• Initial sync took 28 minutes (baseline speed)
   
• New Replication Group with one downstream server
• Pre-seeded data with NTBACKUP on the downstream server
• Initial sync took 24 minutes (~15% faster than baseline)
• Same replication group with original two servers
   
• Added a new third DFSR member
• Pre-seeded data with NTBACKUP on the new downstream server
• Initial sync took 13 minutes (~55% faster than baseline)

55% faster is nothing to blow your nose at – and this is just a small amount of low latency data. If you take a very large set of data on a very slow link with high latency then base initial sync could take for example 2 weeks, out of which only 2 hours are spent to stage files and compute hashes, and the rest by sending data across the wire. In this case pre-seeding may be (1 week - 2 hours) / 1 week = 99% faster. As you can see, the fact that data was already staged upstream meant that we spent considerably less time rolling through the staging directory and didn’t spend most of our time verifying the servers are in sync.

Optimizing pre-seeding

Go here:

http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

To get the most bang for our buck, we can do some of the following to spend the least amount of time populating the staging directory and the most time syncing files:

• Set the staging directory quota on your hub servers as close to the size of your data as possible. Since hub servers tend to be beefier boxes and certainly closer to home than your remote branches, this isn’t a problem for most administrators. If you have the disk space, a staging quota that is the same size as the data volume will give the absolute best results.
  
• When pre-seeding, always use the most recent backup possible and pre-seed off hours. The less data that is in flux in the staging directory while we run through initial replication the better. This may seem like a no-brainer, but customers frequently contact us about slow initial sync that they started at 9AM on a Monday with a terabyte of highly dynamic data!
  
• The latest firmware, chipset, network and disk drivers from your hardware vendor will usually give an incremental performance increase (and not just with DFSR performance). You wouldn’t dream of running your servers without service packs and security hotfixes – why wouldn’t you treat your hardware the same way?

Important Technical Notes (updated 2/28/09)

1. ROBOCOPY - If you use robocopy.exe to pre-seed your data, ensure that you use the permissions on the replicated folder root (i.e.c:\my_replicated_folder) to be identical on the source and target servers before beginning your robocopy commands. Otherwise when you have robocopy mirror the files and copy the permissions, you will get unnecessary 4412 conflict events and perform redundant replication (your data will be fine). The issue here is in how robocopy.exe handles security inheritence from a root folder, and how that can change the overall hash of a file. So using the command-line /COPYALL /MIR /Z /R:0 is perfectly fine  as long as the permissions on the source and destination folder are *identical*. After pre-seeding your data with robcopy, you can always use ICACLS.EXE to verify and synchronize the security if necessary.

2A. NTBACKUP (on Win2003 R2) - If you use NTBACKUP to pre-seed your data on a server where it already hosts DFSR data on that same volume (i.e. you are going to use a new Replicated Folder on the E: drive, and some other data was already being replicated to that E: drive), and you plan on restoring from a full disk backup, you need to understand an important behavior. NTBACKUP is aware of DFSR; NTBACKUP will set a restore key under the DFSR services key in the registry (HKLM\System\CurrentControlSet\Services\DFSR\Restore\<date time> and mark the DFSR service with a non-authoritative restore flag for that volume. The DFSR service will be restarted and the Replicated folders on that volume will do a non-authoritative sync. This should not be destructive to data, but it can mean that you could see your downstream server become unresponsive for minutes or hours while it syncs. When DFSR was written the thought was that NTBACKUP would be used for disaster recovery, where you would certainly be suspicious of the data and DFSR jet database and want consistency sync performed at restore time.

2B. Windows Server Backup (Windows Server 2008 and Windows Server 2008 R2) - same as above but with newer tools. Do not use NTBACKUP to remotely backup or restore WIndows Server 2008 or later. This is unsupported and will mark files HIDDEN and SYSTEM, which you certainly don't want...

3. XCOPY - The XCOPY /O command works correctly even without having the root folder permissions set identically, unlike robocopy. However it is certainly not as roboust and sophisticated as robocopy in other regards. So Xcopy is a valid option, but maybe not powerful enough for many users. 

4. Third party solutions - be wary of third party tools and test them carefully before committing to using them for wide-scale pre-seeding. Thekey thing to remember is that the file hash is everything - if DFSR cannot match the upstream and downstream hashes, it will replicate the file on initial sync. This includes file metadata, such as security ACL's (which are not calculated by tools that do checksum calculating). In Windows Server 2008 R2 beta, check out the DFSRDIAG tool to see how we have made this a bit easier for people. If you really need a file hash checking tool, contact us with a support case, we have some internal ones.

Wrap Up

Finally – I don’t have numbers here for Windows Server 2008 yet, sorry. I can tell you that DFSR behaves the same way in regards to the staging process. Based on the performance improvements made elsewhere though (specifically the 16 concurrent file downloads combined with asynchronous RPC and IO), it should be much faster, pre-seeded or not; that’s the Win2008 DFSR mandate.

Happy pollinating,

- Ned Pyle

Hi, Mike again. Every so often, I’ll talk with a customer wanting to deploy a legal notice to their workstations using Group Policy. Sounds simple, right? Well, it is actually a little tricky to make the legal notice work correctly. Here is a solution that I share with customers that want to do this and have it look right.

It’s a natural assumption to have this done through Group Policy. Every computer in the domain applies it—it makes the job easy. Searching the Microsoft Knowledgebase does yield a few results—here is one.

310430 How to configure Windows Server 2003 to display a message when users log on
http://support.microsoft.com/default.aspx?scid=kb;EN-US;310430

It seems there is a security policy setting that helps us accomplish this task. So, we follow the article and, Figure 1 shows the results.

Figure 1- Configuring a legal caption in security policy

Note:

These examples are from a computer running Windows Vista Service Pack 1 with Remote Server Administration Tools. However, you can use Windows Server 2003 or Windows XP with the Group Policy Management Console (GPMC) to accomplish these results.

Now, notice our Legal Notice on a Windows Vista SP1 computer and on Windows Server 2003 computer

Figure 2- Legal Notice on Windows Vista SP1

Figure 3- Legal Notice on Windows Server 2003

Where is the formatting? How quickly we go from pretty to… “not so pretty”. There’s no way we are going to let the legal department see this. We have to fix it. But first, let’s briefly explain why this is happening.

This problem originates from Windows NT 4; when we added Legal Notice Text to the operating system. At that time, it was a single string and did not support carriage returns. We made several attempts to change this behavior shortly after Windows 2000. Interestingly enough, those changes resulted in using a comma (,) as a delimiter for the carriage return. Kinda cool huh?.... Not! Eight years later, legal council craft very concise legal goo—which just might have a few commas included within the text. Then, administrators would have to enclose grammatical commas in quotation marks so Windows would not parse it as a carriage return. That didn’t work well. In Windows Server 2003, we changed the editor to accept a carriage return; now allowing you to format your text within the policy, as we did in the example. Well, that only solves the comma problem because there was not a change on Windows parses the strings. Windows now inserts the commas and quotes for you when it writes the policy setting. And, as you can see in our example; we started with two paragraphs or more and ended with a single blob of text in window. Lastly, this behavior has not changed with Windows Server 2008 or Windows Vista Service Pack 1. So—how do I format this text?

You need to use a script to have your legal notice text appear properly formatted. Figure 4 shows a script you can use in a computer startup script (not a user logon script). The script writes the legal notice text to the policy registry key—just as if it were applied using the security policy settings. But, the script allows you to keep your formatting.

Here is the code for the script. Copy and paste this code into a text file. Be sure to save the text file with a .vbs extension or it will not run correctly. Each command should appear on its own line (no text wrapping) as some of the text in the example is wrapped for readability.

Figure 4- Sample Vbscript code to write legal caption text

You’ll want to modify the sample code from Figure 4 to include your legal notice. Let me explain the script and which part requires your modifications.

Line 1: set wShell = CreateObject("Wscript.Shell")

This line creates a Windows Scripting Host shell object. The script uses method (or function) from the shell object to write to the registry.

Line 2: strLegalCaption = "Legal Notice"

Line 2 creates a variable named strLegalCaption and assigns the text Legal Notice to the variable. This is the text Windows uses for the title of the legal notice dialog box, which appears when the user presses CTRL+ALT+DEL.

Line 3-5:

Const POLICY_KEY = "HKLM\Software\Microsoft\Windows\CurrentVersion\policies\system\"
Const LEGAL_CAPTION_VALUENAME = "legalnoticecaption"
Const LEGAL_TEXT_VALUENAME = "legalnoticetext"

These lines create what is called a constant. Constants mean just that- they remain constant—their values cannot change; unlike the values of a variable, which can change. Line 3 is representative of the registry key location to which the script writes. Line 4 holds the registry value name for the legal caption (title of the dialog box) while line 5 holds the value of the legal text (message in the dialog box). Constants work similarly to search and replace features found in text editors and word processors. When Windows runs the script, it looks at the constants declared in the script and then searches the remainder of the script for those words which are designated as constants. It then replaces the word with the assigned value. Then, Windows continues running the script.

Line 6: strLegalText = ""

Line 6 creates a variable named strLegalText and assigns and empty string to the variable. The is equivalent to a blank line (without a carriage return).

Line 7:

strLegalText = strLegalText & "The easiest way is to insert the entire paragraph on one
line, between the quotation marks." & vbcrlf & vbcrlf

This line is the important line. This line defines the text of your legal notice ( the text appearing in the dialog box). The registry value name LegalNoticeText is a single string value. Therefore, the script must concatenate your entire legal text notice into one line of text, to include carriage returns. The first part of line 7 shows strLegalText = StrLegalText &. This command phrase handles concatenating your paragraphs into a single line of text; so we can write it into the single string registry value. The next phrase in the script is between the quotation marks. This represents the first paragraph of your legal notice. You’ll want to paste the entire paragraph between the quotation marks. The best way to do this is paste your paragraph into notepad ensuring that word wrap is off (click Format from the menu to ensure there is not a check next to Word Wrap). Position the cursor to the end of the first line. Use the delete key to move the text on the next to the current line. Be sure to keep your spaces. Follow this process until the entire paragraph is on one line (you’ll more than likely have to scroll to the right. Make sure you have an opening and closing quotation marks. It is likely your script will fail if the command is not on a single line.

Important

Quotation mark (“) represents the beginning and end of string when using Vbscript. Any alpha-numeric characters between the quotation marks, including spaces is included in the string—just like if you were typing a long file name as an argument for a command line application. Be certain your legal text does not include any quotation marks. If possible, you single quote marks (‘).

Copy and paste your original line 7 and repeat the above for each paragraph you want included in your legal text. Things to look for are:

• Inserting quotation marks between the beginning and ending quotation marks.
• The entire command is not on a single line
• You keep the & vbcrlf & vbcrlf immediately after the ending quotation mark at the end of each line that represents a paragraph in your legal text.

My legal text notice in this example is three paragraphs with the last paragraph being a single sentence. Therefore, lines 7-9 will look similar for my example script (wrapped for readability—these are three separate commands on three separate lines).

strLegalText = strLegalText & " Alle Menschen sind frei und gleich an Würde und Rechten geboren. Sie sind mit Vernunft und Gewissen begabt und sollen einander im Geist der Brüderlichkeit begegnen." & vbcrlf & vbcrlf

strLegalText = strLegalText & " Alle Menschen sind frei und gleich an Würde und Rechten geboren. Sie sind mit Vernunft und Gewissen begabt und sollen einander im Geist der Brüderlichkeit begegnen." & vbcrlf & vbcrlf

strLegalText = strLegalText & " Alle Menschen sind frei und gleich an Würde und Rechten geboren." & vbcrlf & vbcrlf

Line 8, 9 (Sample script in Figure 4)

wShell.RegWrite POLICY_KEY & LEGAL_CAPTION_VALUENAME, strLegalCaption, "REG_SZ"
WShell.RegWrite POLICY_KEY & LEGAL_TEXT_VALUENAME, strLegalText, "REG_SZ"

These two lines do all the work. Both lines use the Windows Scripting Host shell object to write to the registry of the local computer. This is accomplished using the RegWrite method. The first parameter to the RegWrite method is the full registry path (hive and value name). The second parameter is the value the script writes into the value name. The last parameter is the data type if the value name—in this case both value are strings, which are REG_SZ data types.

Line 8 uses the POLICY_KEY constant and the LEGAL_CAPTION_VALUENAME constant to build the path to which the scripts writes. StrLegalCaption is the variable we used to hold the value of the legal caption. Line 9 uses the POLICY_KEY constant and the LEGAL_TEXT_VALUENAME constant to build the path to which the script writes. StrLegalText is the variable we used to hold the value of the legal text.

Below is the example script created for contoso.com’s legal text notice, which is based on the sample script from Figure 4.

Figure 5- Contoso.com's legal notice script

If you can, disable your existing Group Policy object that contains your legal text notice security policy settings. Now, create a new Group Policy object and assign this at the level appropriate for your environment. Configure this GPO with a computer startup script and include your script. Refresh Group Policy and then logoff your workstation. Press CTRL+ALT+DEL.

Figure 6- Formatted legal notice

- Mike Stephens

New Directory Services-related KB articles for the week. Enjoy!

- Craig Landis

Hi, Mike here. This post was originally published in the Group Policy Team blog in September 2006—anticipating the launch of Windows Vista. Here it is again—refreshed—for the upcoming launch of Windows Server 2008.

User Account Control in Windows Server 2008 and Windows Vista requires all users run in a standard user mode; its purpose: to limit the user’s ability from changing critical operating system files or expose their computer and network to viruses and malware. Windows displays an authorization dialog box when a task requires administrative privileges, such as opening the Microsoft Management Console (MMC). You, the administrator, provide administrative credentials to “elevate” your privileges for the specific process (You can read more about User Account Control, on the Microsoft Windows Vista TechNet site http://www.microsoft.com/technet/windowsvista/security/uacppr.mspx). Windows Server 2008 and Windows Vista provide you with nine security policy settings to control how User Account Control behaves. You can locate these security policy settings in the Local Group Policy Editor under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options or Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options when editing domain-based GPOs using GPMC included in Windows Server 2008 or when using Remote Server Administration Tool on Windows Vista Service Pack 1.

 
Figure 1- UAC security policy parent node in a domain-based GPO.

These security policy settings apply only to computers running Windows Server 2008 or Windows Vista RTM or later. These security policy settings can co-exist in GPOs applicable to clients earlier than Windows Vista. Operating systems other than Windows Server 2008 and Windows Vista ignore the settings.

 
Figure 2- UAC Computer security policy settings

Before I begin, I want to tell you about another feature with security policy settings. This valuable feature is a little hard to find. Each security policy setting has “explain” text similar to registry-based policy settings. Simply double-click on the security policy setting and then click on the Explain tab to view detailed information about the security policy setting; enabled and disabled behavior; and default values. Now, let us move on to the User Account Control policy settings.

Figure 3 - Explain text in Security policy settings

Windows Vista provides nine security policy settings to control the behavior of User Account Control. You can enable these security policy settings in Local Computer and Domain-based Group Policy objects. Each security policy setting starts with “User Account Control” and then the actual name of the policy settings. The Group Policy Object Editor lists security policy settings in alphabetical order, so just scroll to the end.

The first of these policies controls the Admin Approval Mode for the built-in administrators account. When enabled, the Admin Approval mode is on for the built-in administrator account causes Windows prompts the administrators for any operations requiring an elevation in privilege. The prompt gives the administrator the choice to Permit or Deny the request for elevation. When disabled, Admin Approval mode is off. The built-in administrator account runs all applications using full administrative privileges and does not prompt for elevation.

The next two security policy settings control the type of prompt for User Account Control uses. These security policy settings are Behavior of the elevation prompt for administrators in Admin Approval Mode and Behavior of the elevation prompt for standard users. Behavior of the elevation prompt for administrators in Admin Approval Mode security policy setting provides three choices

• Prompt for Consent –provides a dialog box asking you to either Permit or Deny the request for elevation.
• Prompt for Credentials –provides an authentication dialog box asking you to provide administrative credentials to permit the request for elevation.
• Elevate without Prompting –automatically permits the request for elevation without prompting the administrator.

The Behavior of the elevation prompt for standard users security policy setting provides two choices. Prompt for Credentials and Automatically deny elevation requests where Windows denies all requests for elevation and displays an Access Denied error message.

When enabled, the Detect application installation and prompt for elevation security policy setting causes Windows to detect heuristically for installation packages that require an elevation of privilege and triggers a User Account Control prompt for elevation. Disabling this security policy setting disables detection process.

Enabling the security policy setting Only elevate executables that are signed and validated enforces Windows Vista to validate the Public Key Infrastructure (PKI) certificate chain before permitting it to run. Disabling this security policy setting does not enforce validation of the PKI certificate chain.

The next security policy setting listed is, Only elevate UIAccess applications that are installed in secure locations. UIAccess applications are applications designed specifically to assist with user accessibility. These applications typically send information to other applications. The on-screen keyboard is an example of a UIAccess application. When enabled, Windows enforces UIAccess application to run from a secure location. These secure locations include:

• …\Program Files\... including all sub folders.
• …\Windows\System32\...
• …\Program Files (x86)\... including all sub folders (64-bit versions).

Your desktop appearance changes when Windows Vista prompts you for elevation. Windows displays a gradient shade of gray over your existing desktop and then you see the prompt for elevation, in color. Actually, Windows switches your desktop to a secure desktop before prompting you for elevation. This describes the enabled behavior of the security policy setting Switch to the secure desktop when prompting for elevation. When disabled, Windows prompts for elevation on your existing desktop.

Some applications read or write registry information or files to locations that Windows protects from normal users. This usually requires the user to run the application as an administrator until an application upgrade becomes available. Windows Vista helps by providing virtualized file and registry writes to areas previously protected from normal users. This feature redirects writes destined for protected locations to locations where users have write access. The security policy setting Virtualize file and registry write failures to per-user locations provides this behavior, when enabled. When you disable this security policy setting, applications attempting to write in protected locations fail as with earlier versions of Windows.

The last security policy setting controlling User Account Control behavior is probably the most important one. Run all users, including administrators, as standard users is a security policy setting the affects all other User Account Control security policy settings. Enabling this policy turns on Admin Approval Mode and enables all other User Account Control polices to their default values. Disabling this policy turns off Admin Approval Mode and disables all related User Account Control security policy settings. Lastly, changing this security policy setting requires a reboot.

So, when you are evaluating your security policy during your Windows Server 2008 or Windows Vista deployment, look at the explain text for each security policy setting. Make sure you fully understand its impact before changing a security policy setting. Then, do not forget to include User Account Control policy settings in your security policy. These security policy settings can help you keep your computer, network, and data safe and secure.

- Mike Stephens

Here are the new Directory Services-related KB articles for the week. Also, although it isn't entirely new, I was reminded that we have the Windows Server 2008 command reference available now. So here are links to both the 2008 and 2003 versions. They are good as a quick reference when you need a command's syntax but also interesting to look at to be aware of tools you might not use on a daily basis. AD admins will want to familiarize themselves with Wevtutil and Icacls, both are new to Vista/2008.

Windows Server 2008 Command Reference

Windows Server 2003 Command-Line Reference

- Craig Landis

Hi, Ned here. If you’re a regular reader of the Filing Cabinet, you’ve probably already read about all the new features for DFS Replication (DFSR) added in Windows Server 2008. If not, trot on over here and drink your fill. Just to summarize some of these cool new features:

But there’s something missing. There’s a little history here, so walk with me down technical memory lane.

When DFSR was released on Windows Server 2003 R2 in February 2006, it had a list of file extensions that were non-compressible. These were:

WMA,WMV,ZIP,JPG,MPG,MPEG,M1V,MP2,MP3,MPA,CAB,WAV,SND,AU,ASF,
WM,AVI,Z,GZ,TGZ,FRX

When you added a file to a DFSR content set and it was at least 64KB in size, the DFSR service placed a copy of the file in the Staging folder. The file had an alternate data stream added that held the computed Remote Differential Compression (RDC) signatures. RDC is what allows DFSR to only replicate the parts of the file that have changed. But files were also compressed with a standard compression algorithm called XPRESS, which is similar to ZIP or RAR compression. Any files that ended up in staging were compressed with XPRESS unless they had an extension that was on this list. Since there was no point in trying to shrink files that were already compressed (like ZIP or JPG), we simply didn’t bother; it wasted disk and CPU resources after all.

After digging around in the product design request database here, looking at the source code, and pinging the developers, I came up short: the list was hardcoded. Rats. I wrote up a short internal article and promptly forgot about it.

Fast forward to Windows Server 2008.

You guessed it – we can do this now and here are the steps:

1. Your Active Directory forest schema must have been extended with ADPREP to Windows Server 2008 (or you have installed a new Win2008 forest). If this is not done you won’t have the new attribute necessary for this to work.

2. Setup DFSR on a few Win2008 machines (add the role through Server Manager, use DFSMGMT.MSC to configure, and let the servers pick up the new settings).

3. On one of your domain controllers run ADSIEDT.MSC as a Domain Administrator.

4. Navigate to your content set that you want to modify. So for example:

cn=Public,cn=content,cn=Shared, cn=dfsr-globalsettings,cn=system,dc=cohowinery,dc=com

5. Right-click the replicated folder (cn=public) and choose properties.

6. Scroll down a ways and edit the attribute msDFSR-DefaultCompressionExclusionFilter.

Important Notes: Any extensions we add in here will become the new rule for compression. So if we just add FOO then all files that are *.foo will no longer be compressed. We need to make sure we comma separate a list of files, and there must not be any spaces. Also, this list is destructive – if we put anything in here, then the default list of extensions like ZIP or JPG is ignored going forward unless we add them back. Finally, if the attribute is set to “<Not Set>” it will use the default extension list from above.

7. So let’s add our new extension. We have an application that creates drawing files called *.NED. These NED files are already compressed so we don’t want DFSR to waste time trying to compress them more. In the Value field of our msDFSR-DefaultCompressionExclusionFilter attribute we all of the below:

WMA,WMV,ZIP,JPG,MPG,MPEG,M1V,MP2,MP3,MPA,CAB,WAV,SND,
AU,ASF,WM,AVI,Z,GZ,TGZ,FRX,NED

8. We click ok and exit out of ADSIEDIT. We wait for AD replication to complete. We wait for the DFSR servers to pick up the change through their polling process (or run DFSRDIAG POLLAD).

Now when NED files are created or modified, they will no longer be compressed in the staging directory. Sweet! If for some reason you wanted to turn off all file compression, you can set the msDFSR-DefaultCompressionExclusionFilter attribute to contain just an asterisk. This would have the minor upside of saving some CPU and disk time when staging, but could have a significant downside in bandwidth consumption and replication time for larger files – so this is not recommended and you shouldn’t do this without significant testing in your lab environment. You cannot tailor RDC to only affect certain file types – it is limited to off/on/minimum size, just like in R2.

And yes, we have a KB article for this in the works. The beauty of blogging means you don’t have to wait for it. :)

- Ned Pyle