February, 2009

Question

How often does the machine password account change in AD (is it different for various Windows operating systems)?

Answer

The machine account password change is initiated by the computer every 30 days by default . Since Windows 2000, all versions of Windows have the same value. This behaviour can be modified to a custom value using the following group policy setting in Active Directory.

Domain member: Maximum machine account password age
You can configure this security setting by opening the appropriate policy and expanding the console tree as such:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Question

If a workstation does not change its password, will it not be allowed to log onto the network?        

Answer

Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.
Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally.

The relevant Netlogon parameters that come into play and we can think about changing here are:

ScavengeInterval (default 15 minutes),
MaximumPasswordAge (default 30 days)
DisablePasswordChange (default off).

DisablePasswordChange would prevent the client computer from changing its computer account password.

Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value = DisablePasswordChange REG_DWORD
Default = 0

Group policy setting:
Computer Configuration\windows Settings\Security settings\Local Policies\Security Options
Domain member: Disable machine account Password changes    

Warning: If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller. Here is the article that talks about disabling automatic machine account password change: KB 154501

ScavengeInterval controls how often the workstation scavenger thread runs - the workstation scavenger is responsible for changing the machine password if necessary:

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value: ScavengeInterval REG_DWORD 60 to 172800 Seconds (48 hours)
Default : 900 (15 minutes)

MaximumPasswordAge determines when the computer password needs to be changed.

Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Value = MaximumPasswordAge REG_DWORD
Default = 30
Range = 1 to 1,000,000 (in days)

Group policy setting:
Computer Configuration\windows Settings\Security settings\Local Policies\Security Options

Domain member: Maximum machine account Password age

To clear things up, it is 7 days on Windows NT by default, and 30 days on Windows 2000 and up. The trust password follows the same setting. So Trust between two NT 4 domains is 7 days. Trusts between Windows 2000 and up and anything else is 30 days. So what this means is if:

• 2000 and NT4 trust password is 30 days
• 2000 to 2000 is 30 days
• 2000 to 2003 is 30 days
• 2003 to 2003 is 30 days

After the Netlogon service starts, the Workstation service scavenger thread wakes up. If the password is not older than MaximumPasswordAge, the scavenger thread goes back to sleep and sets itself to wake up when the password will reach that age. Otherwise, the scavenger thread will attempt to change the password. If it cannot talk to a DC, it will go back to sleep and try again in ScavengeInterval minutes.    

The ScavengeInterval setting can be modified to a custom value using the group policy setting in Active Directory.

Group policy setting:
Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval

Further we have given the following clarification regarding the behavior described
in: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/55944.mspx?mfr=true

Question

How do computers actually use passwords?

Answer

Each Windows-based computer maintains a machine account password history containing the current and previous passwords used for the account. When two computers attempt to authenticate with each other and a change to the current password is not yet received, Windows then relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may be unable to communicate, and you may receive error messages.

When a client determines that the machine account password needs to be changed, it would try to contact a domain controller for the domain of which it is a member of to change the password on the domain controller. If this operation succeeds then it would update machine account password locally.

The client first changes the password locally and then attempts to update it in Active Directory. If the domain controller is configured with security policy "Domain Controller: Refuse machine account password changes" (i.e. RefusePasswordChange, see here and here), then the client rolls back locally to the previous password. If the password change fails, however, the client keeps the new password locally and keeps trying to set it on the scavenge interval until it succeeds.

The local copy of the machine password is stored under:

HKLM\SECURITY\Policy\Secrets\$machine.ACC

We store the current password and the previous password under CurrVal & OldVal Keys respectively. In Active Directory, we store the password in unicodepwd and lmpwdHistory. We also store the timestamp in the pwdlastset attribute (the method to convert it into readable format is:

• Convert the value in the attribute from decimal to hex (using calc.exe)
• Split the result into two equal parts (8 bits for each part)
• Run nltest /time: rightsidehex leftsidehex

The resultant value is the date and time the password was set on this computer object in AD. The cases where in you could run into problems that the KB260575 describes would be:
If you use System Restore after the password change interval expired one time, and you restore the computer to a point before the password changes, the next password change may not occur when it is due. Instead, the operating system treats the restore as if the password was changed.

Now consider the scenario, when a machine is not connected to the network for a long period. Supposing on the client:

• Old password = null
• Current password = A
• New random password = B

And on the machine account in AD:

• unicodePWD = A

After 30 days when the Scavenger thread runs, the value would be:

• Old Password = A
• Current Password = B

At 60th day the same process happens again. So now the newly generated password is C and the values are:

• Old password = B
• Current Password = C

Now when the client connects to AD, it will try the current password to authenticate. When that fails with error. Otherwise machine should be able to reset its password once it boots even after say 90 days.

Further reading:

How to detect and remove inactive machine accounts
http://support.microsoft.com/default.aspx?scid=kb;EN-US;197478

How to disable automatic machine account password changes
http://support.microsoft.com/default.aspx?scid=kb;EN-US;154501

Effects of machine account replication on a domain
http://support.microsoft.com/default.aspx?scid=kb;EN-US;175468

Domain member: Disable machine account password changes
http://technet.microsoft.com/en-us/library/cc785826.aspx

Domain member: Maximum machine account password age
http://technet.microsoft.com/en-us/library/cc781050.aspx

Account Passwords and Policies
http://technet.microsoft.com/en-us/library/cc783860.aspx

-       Manish Singh

[Updated with a strict clarification of the client local password rollback behavior 7-19-2012; thanks for asking, Joe - Ned]

Ned here again. Today’s post is probably going to generate some interesting comments. I’m going to discuss the absence of a multi-host distributed file locking mechanism within Windows, and specifically within folders replicated by DFSR.

Some Background

• Distributed File Locking – this refers to the concept of having multiple copies of a file on several computers and when one file is opened for writing, all other copies are locked. This prevents a file from being modified on multiple servers at the same time by several users.
  
• Distributed File System Replication – DFSR operates in a multi-master, state-based design. In state-based replication, each server in the multi-master system applies updates to its replica as they arrive, without exchanging log files (it instead uses version vectors to maintain “up-to-dateness” information). No one server is ever arbitrarily authoritative after initial sync, so it is highly available and very flexible on various network topologies.
  
• Server Message Block - SMB is the common protocol used in Windows for accessing files over the network. In simplified terms, it’s a client-server protocol that makes use of a redirector to have remote file systems appear to be local file systems. It is not specific to Windows and is quite common – a well known non-Microsoft example is Samba, which allows Linux, Mac, and other operating systems to act as SMB clients/servers and participate in Windows networks.

It’s important to make a clear delineation of where DFSR and SMB live in your replicated data environment. SMB allows users to access their files, and it has no awareness of DFSR. Likewise, DFSR (using the RPC protocol) keeps files in sync between servers and has no awareness of SMB. Don’t confuse distributed locking as defined in this post and Opportunistic Locking.

So here’s where things can go pear-shaped, as the Brits say.

Since users can modify data on multiple servers, and since each Windows server only knows about a file lock on itself, and since DFSR doesn’t know anything about those locks on other servers, it becomes possible for users to overwrite each other’s changes. DFSR uses a “last writer wins” conflict algorithm, so someone has to lose and the person to save last gets to keep their changes. The losing file copy is chucked into the ConflictAndDeleted folder.

Now, this is far less common than people like to believe. Typically, true shared files are modified in a local environment; in the branch office or in the same row of cubicles. They are usually worked on by people on the same team, so people are generally aware of colleagues modifying data. And since they are usually in the same site, the odds are much higher that all the users working on a shared doc will be using the same server. Windows SMB handles the situation here. When a user has a file locked for modification and his coworker tries to edit it, the other user will get an error like:

And if the application opening the file is really clever, like Word 2007, it might give you:

DFSR does have a mechanism for locked files, but it is only within the server’s own context. As I’ve discussed in a previous post, DFSR will not replicate a file in or out if its local copy has an exclusive lock. But this doesn’t prevent anyone on another server from modifying the file.

Back on topic, the issue of shared data being modified geographically does exist, and for some folks it’s pretty gnarly. We’re occasionally asked why DFSR doesn’t handle this locking and take of everything with a wave of the magic wand. It turns out this is an interesting and difficult scenario to solve for a multi-master replication system. Let’s explore.

Third-Party Solutions

There are some vendor solutions that take on this problem, which they typically tackle through one or more of the following methods*:

• Use of a broker mechanism

Having a central ‘traffic cop’ allows one server to be aware of all the other servers and which files they have locked by users. Unfortunately this also means that there is often a single point of failure in the distributed locking system.

• Requirement for a fully routed network

Since a central broker must be able to talk to all servers participating in file replication, this removes the ability to handle complex network topologies. Ring topologies and multi hub-and-spoke topologies are not usually possible. In a non-fully routed network, some servers may not be able to directly contact each other or a broker, and can only talk to a partner who himself can talk to another server – and so on. This is fine in a multi-master environment, but not with a brokering mechanism.

• Are limited to a pair of servers

Some solutions limit the topology to a pair of servers in order to simplify their distributed locking mechanism. For larger environments this is may not be feasible.

• Make use of agents on clients and servers
• Do not use multi-master replication
• Do not make use of MS clustering
• Make use of specialty appliances

* Note that I say typically! Please do not post death threats because you have a solution that does/does not implement one or more of those methods!

Deeper Thoughts

As you think further about this issue, some fundamental issues start to crop up. For example, if we have four servers with data that can be modified by users in four sites, and the WAN connection to one of them goes offline, what do we do? The users can still access their individual servers – but should we let them? We don’t want them to make changes that conflict, but we definitely want them to keep working and making our company money. If we arbitrarily block changes at that point, no users can work even though there may not actually be any conflicts happening! There’s no way to tell the other servers that the file is in use and you’re back at square one.

Then there’s SMB itself and the error handling of reporting locks. We can’t really change how SMB reports sharing violations as we’d break a ton of applications and clients wouldn’t understand new extended error messages anyways. Applications like Word 2007 do some undercover trickery to figure out who is locking files, but the vast majority of applications don’t know who has a file in use (or even that SMB exists. Really.). So when a user gets the message ‘This file is in use’ it’s not particularly actionable – should they all call the help desk? Does the help desk have access to all the file servers to see which users are accessing files? Messy.

Since we want multi-master for high availability, a broker system is less desirable; we might need to have something running on all servers that allows them all to communicate even through non-fully routed networks. This will require very complex synchronization techniques. It will add some overhead on the network (although probably not much) and it will need to be lightning fast to make sure that we are not holding up the user in their work; it needs to outrun file replication itself - in fact, it might need to actually be tied to replication somehow. It will also have to account for server outages that are network related and not server crashes, somehow.

And then we’re back to special client software for this scenario that better understands the locks and can give the user some useful info (“Go call Susie in accounting and tell her to release that doc”, “Sorry, the file locking topology is broken and your administrator is preventing you from opening this file until it’s fixed”, etc). Getting this to play nicely with the millions of applications running in Windows will definitely be interesting. There are plenty of OS’s that would not be supported or get the software – Windows 2000 is out of mainstream support and XP soon will be. Linux and Mac clients wouldn’t have this software until they felt it was important, so the customer would have to hope their vendors made something analogous.

The Big Finish

Right now the easiest way to control this situation in DFSR is to use DFS Namespaces to guide users to predictable locations, with a consistent namespace. By correctly configuring your DFSN site topology and server links, you force users to all share the same local server and only allow them to access remote computers when their ‘main’ server is down. For most environments, this works quite well. Alternative to DFSR, SharePoint is an option because of its check-out/check-in system. BranchCache (coming in Windows Server 2008 R2 and Windows 7) may be an option for you as it is designed for easing the reading of files in a branch scenario, but in the end the authoritative data will still live on one server only – more on this here. And again, those vendors have their solutions.

We’ve heard you loud and clear on the distributed locking mechanism though, and just because it’s a difficult task does not mean we’re not going to try to tackle it. You can feel free to discuss third party solutions in our comments section, but keep in mind that I cannot recommend any for legal reasons. Plus I’d love to hear your brainstorms – it’s a fun geeky topic to discuss, if you’re into this kind of stuff.

- Ned ‘Be Gentle!’ Pyle

Hi, Gary from DS here and I am going to discuss the “Configure slow-link mode” policy on Vista with Offline Files.

How is slow link determined by Windows Vista?

Offline Files measures the speed of a link based on the packet latency between the client and the target server. This is reported by the network driver and TCP stack and is then used to compute the throughput to the server for comparison with the configured throughput and/or latency policy configuration. You might think that the NLA service (Network Location Awareness) service would be used in this, but that is not the case.

The original released version of Windows Vista only took into account outbound traffic, which means that share might remain online longer than expected. Windows Vista SP1 further improves this feature by taking into account both the inbound and outbound traffic. Out of those two, values it takes the smaller of them when determining if a transition to slow link is needed.

The “Configure slow-link mode” policy MUST be configured in order for anything to be considered slow. By default, nothing is considered slow automatically.

Configuring the policy

The policy itself is pretty easy to configure, but the example text can be a bit confusing. I have seen a few cases where these have been defined incorrectly. The policy is located in the following path of the Group Policy Editor as shown below:

Computer Configuration\Administrative Templates\Network\Offline Files

Say you are configuring the slow link policy and you want \\server\share to be offline with an acceptable latency of 50 milliseconds, you would fill in the boxes as shown below:

Support for wildcards (*)

As the screen shot sample of the policy above suggests, there is some limited support for wildcards within the policy for determining what to consider for slow link detection. The matching algorithm is pretty simple and separates the path into 5 different parts (Server, Share, Directories, Filename, and Extension):

\\servername\share\dir1\dir2\file.ext
| SRV       | SH  | DIR | F | E     |

SRV = Server Name
SH = Share name
DIR = Directory name
F = File name
E = File Extension

The wildcard character ‘*’ can be specified for one or more of the parts in which the wildcard means “anything is matched”. The following rules apply to the matching:

• If a path contains a trailing *, then the remaining parts are matched automatically.
• When the directories part contains a *, all remaining directory parts are automatically matched.
• The * does not support partial matching. Example: \\server\share\mydir* would not match \\server\share\mydirectories as it would be explicitly looking for “mydir*” in the path.

With these rules there is some flexibility with regards to setting up matching patterns. In my experience so far and because Offline Files doesn’t take individual files offline it is best to match the share or DFS link that will be considered for slow link transition. In testing the following patterns had these results:

For a DFS Namespace that has the following structure and you want to have:

\\contoso.com\dfsroot

\Site1\Users – Link to a target that contains user’s data
\Site2\Users – Link to a target that contains user’s data

To quickly summarize, the slow link is determined by network packet latency and is compared with the configured policies. This policy must be configured for anything to automatically transition to offline. Also, there is basic support for wildcard matching that could help in fine tuning slow link settings for specific paths, instead of having to have multiple entries or multiple policies. A better understanding of how that works will help make that easier.

- Gary ‘Always Online’ Mudgett

I’m guessing Ned will insert something like “Hello, Warren here again”. [Nope – Ned]

The other day I was working with server core and wanted to rename my server. Recently I have been working more with WMIC to get data from the DFSR service so I thought why not try WMIC?

Renaming a computer with WMIC

To rename a computer we can use the “Rename” method of the “Win32_ComputerSystem” WMI class. The command looks like this:

WMIC ComputerSystem where Name=COMPUTERNAME call Rename Name=NewName

Don't forget to reboot as you will not be prompted to restart the system.

Netdom can do the same thing

Don’t forget that you can also rename a computer using Netdom. You may find the Netdom method more user friendly if you are just renaming one system. Using WMIC may come in handy if you need to script the renaming of several machines or just want show off your “skills” to coworkers.

325354 How To Use the Netdom.exe Utility to Rename a Computer in Windows Server 2003 - http://support.microsoft.com/default.aspx?scid=kb;EN-US;325354

Netdom is part of the Support Tools for Windows 2003. In Windows 2008 it is included in the OS install.

“Invalid Global Switch” error

I noticed while working with renaming a computer with WMIC I would sometimes get an “Invalid Global Switch” error. After digging a bit I found that WMIC does not handle special characters. If there are dashes in any of the names used the command will fail unless they are enclosed with quotes. Just so happens I always use dashes in my computer names. So if the command was formatted as shown below it would fail.

WMIC ComputerSystem where Name=COMPUTER-NAME call Rename Name=NewName

To get this command to run you would need to enclose the name in quotes

WMIC ComputerSystem where Name="COMPUTER-NAME" call Rename Name=NewName

This command also takes environment variables, so if you have been using SYSPREP and have computer names that are gross, you can save time by using the %computername% variable:

Happy computer renaming!

- Warren Allen Williams

Ravi here from Directory Services team; I thought I would share some information on how to enable the Event Logging for Offline Files, (Client Side Caching) in Windows Vista.

Offline Files Changes in Windows Vista

Offline Files has been completely redesigned for Windows Vista, offering new features, which include:

•    Better defined modes of operation
•    Seamless offline to online transitions
•    Optimized file synchronization
•    Improved slow-link mode
•    Consistent namespaces
•    Cache size management
•    Per-user encryption
•    Scriptable API support

For more information refer below article.
What's New in Offline Files for Windows Vista

There are certain changes in Group Policies for Offline Files in Vista.
All the Group Policy settings for Offline Files can be found through two paths:

Computer Configuration\Administrative Templates\Network\Offline Files
User Configuration\Administrative Templates\Network\Offline Files

Along with some other Policy changes, “Event Logging Level” have also been changed, there is no Group Policy setting for the enabling Advance Event logging.

Note: Windows XP based computer needs this policy to be set at the value of 3, which will result in verbose events getting written in the System Event log.

Event Logging in Windows Vista

Event logging is not something an end user would have to care about but it may be necessary during troubleshooting problems with Offline Files. Windows Vista has also considerably changed when it comes to Event logging.

The Event Viewer includes a new category of event logs “Applications and Services logs” apart from native “Windows Logs”. These logs store events from a single application or component.

This category of logs includes four subtypes: Admin, Operational, Analytic, and Debug logs. Events in Admin logs are of particular interest to IT Professionals using the Event Viewer to troubleshoot problems. Events in the Admin log should provide you with guidance about how to respond to them. Events in the Operational log are also useful for IT Professionals, but they are likely to require more interpretation.

Following are the instructions on enabling the logging for “OfflineFiles” subsystem.

“Operational” event logging for Offline Files is itself disabled by default. Below are the steps to enable it.

• To enable "Operational" log by using the Windows interface.

1. Start Event Viewer. (Eventvwr.msc).
2. In the console tree, navigate to and select the "Applications and Services logs”. Select "Microsoft”. Select and expand "Windows".
3. Select "OfflineFiles" from the list. Select the log "Operational".
4. On the “Actions” menu, click "Enable Log".

• To enable Operational" logs by using a command line.

1. Open a command prompt in Run as Administrator mode.
2. Type the following text:

    wevtutil sl  Microsoft-Windows-OfflineFiles/Operational  /e:true

Note: To get the available log names type, wevtutil el

How to turn on advance logging.

“Operational” log will only write the informational event. Advance logging can be enabled by following below steps.

• Enable Analytic and Debug Logs
  
  Ensure that Analytic and Debug logs are visible.
  
• To show or hide analytic and debug logs

1. Start Event Viewer.
2. Select "Applications and Services logs' Click the View menu.
   If Show Analytic and Debug Logs is selected, Analytic and Debug logs are already visible. 
   No further action is required. If Show Analytic and Debug Logs is not selected, select Show Analytic and Debug Logs to make these logs visible. 
   Note that a check mark should appear to the left of the menu option.

• To enable Analytic and Debug logs by using the Windows interface

1. Start Event Viewer.
2. In the console tree, navigate to "OfflineFiles" below "Applications and Services logs" and select the Analytic Debug or Synclog you want to enable.
3. On the “Actions” menu, click "Enable Log".

• To enable Analytic and Debug logs by using a command line

1. Open a command prompt in Run as Administrator mode.
2. Type the following text:
   
   wevtutil sl Microsoft-Windows-OfflineFiles/Analytic /e:true
   wevtutil sl Microsoft-Windows-OfflineFiles/Debug  /e:true
   wevtutil sl Microsoft-Windows-OfflineFiles/SyncLog  /e:true

Sample Events:

Log Name:      Microsoft-Windows-OfflineFiles/Operational
Source:        Microsoft-Windows-OfflineFiles
Date:          2/9/2009 8:34:16 PM
Event ID:      9
Task Category: None
Level:         Information
Keywords:      Online/offline transitions
User:          SYSTEM
Computer:      machine1.contoso.com
Description:
Path disconnected.
\\server\Public\Tools

Log Name:      Microsoft-Windows-OfflineFiles/Operational
Source:        Microsoft-Windows-OfflineFiles
Date:          2/9/2009 8:35:54 PM
Event ID:      10
Task Category: None
Level:         Information
Keywords:      Online/offline transitions
User:          SYSTEM
Computer:      machine1.contoso.com
Description:
Path reconnected.
\\server\Public\Tools

Above events are written a when a Network share which is set to be “available offline” is disconnected and reconnected.

Log Name:      Microsoft-Windows-OfflineFiles/SyncLog
Source:        Microsoft-Windows-OfflineFiles
Date:          2/6/2009 3:31:46 AM
Event ID:      2002
Task Category: None
Level:         Information
Keywords:     
User:          CONTOSO\user1
Computer:      machine1.contoso.com
Description:
Sync info for \\server\Public\Tools
Both client and server copies exist.
DirChangedOnServer

Log Name:      Microsoft-Windows-OfflineFiles/SyncLog
Source:        Microsoft-Windows-OfflineFiles
Date:          2/9/2009 8:53:16 PM
Event ID:      2002
Task Category: None
Level:         Information
Keywords:     
User:          CONTOSO\user1
Computer:      machine1.contoso.com
Description:
Sync info for \\server\Public
Both client and server copies exist.
Stable

Above Events is indication of sync action performed.

Log Name:      Microsoft-Windows-OfflineFiles/SyncLog
Source:        Microsoft-Windows-OfflineFiles
Date:          2/9/2009 8:29:56 PM
Event ID:      2005
Task Category: None
Level:         Information
Keywords:     
User:          CONTOSO\user1
Computer:      machine1.contoso.com
Description:
Sync succeeded.
\\adportal\Public
Operation: Encrypt or unencrypt directory tree in cache

Above Event is written while either encrypting or decrypting the offline cache.

Consideration when advance logging is enabled.

When enabled Analytic and Debug logs can quickly fill with a large number of entries. For this reason, you will probably want to turn them on for a specified period to gather some troubleshooting data and then turn them off again. You can perform this procedure by using either the Windows interface or a command line.
Note that the procedure documented here can also be implemented for other Applications or Services.

Changes to Offline Files in Windows Vista
Event Logging in Windows Vista

-    Ravi Bakamwar

Craig here. We’ve had some nasty cases related to this bug, so it seemed prudent to do our best to increase the awareness of this issue. In a nutshell, the DNS Server service in Windows Server 2008 has a bug that can result in a large number of DNS records disappearing. When those records go missing, you will start seeing problems with anything that depends on name resolution, which in an Active Directory environment is pretty much everything. Note this hotfix only applies to standard secondary zones. Active Directory-integrated zones are not affected by this issue because they use AD replication, not zone transfers, to stay synchronized.

For this reason, we recommend that you take a look at the following KB article and consider applying the hotfix to your environment.

953317 A primary DNS zone file may not transfer to the secondary DNS servers in Windows Server 2008
http://support.microsoft.com/kb/953317

If you are hitting this issue, you may see the following event logged:

Event Type: Error
Event Source: DNS
Event Category: None
Event ID: 6527
Date: 8/21/2008
Time: 3:20:34 PM
User: N/A
Computer: Server01.contoso.com
Description: Zone contoso.com expired before it could obtain a successful zone transfer or update from a master server acting as its source for the zone. The zone has been shut down.

The problem is specific to Windows Server 2008 SP1 (meaning the original release of Windows Server 2008). The 953317 hotfix version of DNS.EXE is 6.0.6001.22218. The problem may occur on both secondary DNS servers that were upgraded from Windows Server 2003 and also new installs of Windows Server 2008. For this issue to reproduce, a master server must be hit with enough changes that it cannot service an IXFR request, and so will respond to IXFR with an AXFR.

What you will see is that most of the records in the DNS zone will appear to have disappeared, expired, or been deleted. The zone itself continues to exist but virtually all records in the zone are deleted except for the Start of Authority (SOA) records. Often a handful of host “A” records will also remain present in the zone.

Because DNS servers affected by this condition continue to host a copy of the zone, they will continue to respond to queries from clients. The typical response returned by DNS servers with deleted zone contents is that the record queried do not exist (this assumes that the DNS server role is otherwise functional) in the zone. Windows clients will continue to direct queries to responsive DNS servers instead of failing over to an alternate DNS server that hosts a complete copy of the zone.

Keywords: Windows Server 2008 secondary master primary zone transfer zone axfr ixfr incremental zone transfer full zone transfer delete deleted disappear disappeared missing expired expire

- Craig Landis

Hi, this is Amit from the Directory Services team and I am going to discuss a Group Policy setting which is now available in XP SP3 & 2003 SP2.

Whenever we logon to a Windows workstation, we always see a previously logged on user; we might want to remove that because of Security Reasons. We already have a KB Article for this 324740.

Ever wonder if we can hide Domain\Username details, when computer is locked? After all, users can still look at the actual username, Domain Name etc. being used (see below).

If you want to hide these details, then you can configure this using a GPO setting:

Interactive Logon: Display User Information when the session is locked.

This setting is available at the following location:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

This setting has three options when you enable it:

• User display name, domain and user names (Value = 0x1)
• User display name only (Value = 0x2)
• Do not display user information (Value =0x3)

By choosing the third option, you are not displaying DOMAIN\Username details when the machine is locked (see below).

Once the policy is applied, it will create a registry key “DontDisplayLockedUserId” with a value of 3 at the following location :

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\

When you try to login back on the locked machine, it will not show the user name who is logged on. So you have to provide your username again along with the password.

Note: - This group policy is only available via the group policy editor XP SP3 & 2003 SP2; however it can also be directly applied by editing the registry to XP SP2, Windows Vista & Windows Server 2008 computers.

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
REG_DWORD: DontDisplayLockedUserId

We are aware of this issue that this setting is currently not available on Windows Vista & Windows Server 2008.

You can also refer to KB837022 which talks about hot fix for MSGINA.DLL .

You cannot change the display behavior of the user display name and of the user ID when a Windows XP-based computer resumes from the locked state.

If you want to learn more about Group Policy and play around with other settings, check out the following links:

Group Policy Resources on TechNet

Download Group Policy Settings Reference for Windows Vista

Download Group Policy Settings Reference for Windows Server 2008 and Windows Vista SP1

www.gpoguy.com This site has helpful videos, articles, and tools to help you work with Group Policy.  Check that site out regardless, beta or not. It’s got a lot of good information for every level of GP knowledge

- Amit Khanna

Hi, Russell here. I’m a member of the Microsoft Texas Directory Services Team. I specialize in all things LDAP, with particular focus on 3^rd Party LDAP Client interop, ADAM & AD LDS, Directory Service Schemas, Indexing, and LDAP Query Performance Tuning.

We recently had a customer who had "inherited" an ADAM infrastructure. He called concerning replication failures between ADAM instances. Trouble was, he had no documentation explaining the configuration. Fortunately, AD LDS and ADAM have many tools to help you sort out the confusion after the fact. One of them is LDIFDE, which is the MS version of a tool that imports and exports in the LDAP Data Interchange Format (LDIF) RFC2849 Spec.

To assist the customer, we asked for an LDIFDE export of his ADAM Configuration Partition to view the ADAM NTDS Settings Objects and Site configurations.

Problem - The command line help leaves a bit to be desired. While export mode of operation is the default for ldifde, we did not require a full output of all ADAM Partitions, #1; nor would the macro expansion feature give us the desired results, #2:

1. LDIFDE -m -f output.ldf

2. LDIFDE -f export.ldif -c "#configurationNamingContext" "cn=configuration,dc=x"

Complicating matters, if the machine is in a domain, the export will occur from the first DC to respond, not ADAM if ADAM is listening on any port other than 389. See the fine print at the end.

To obtain just the Configuration Container for analysis, we'll need to supply LDIFDE more information:

•  -d Specifies the Root Container of our search & export
  
• -s Specifies the Server we want to connect to. Localhost can be used if running locally on ADAM
  
•  -t Specifies the ADAM port you want to connect to (Use dsdiag.exe “List Instances” sub-command to determine the port if not known)
  
•  -f Specifies the file name where you want to write the output of the export

Order is important. Use the -d switch first, then the server, port, and an output file name.

Example:

LDIFDE -d CN=Configuration,CN={43B6F689-F8B3-47B5-BB75-5B56BB5A55} –s  localhost -t 50000 -f ServerConfig.ldif

NOTES – CN=GUID is from a sample machine. Each configuration container will have a unique GUID. Replica members will share this GUID. Possible errors you might encounter when syntax is incorrect:

"The default naming context cannot be found. Using NULL as a search base."
"No entries found."

Fine Print on the above error - This is actually an issue with LDIFDE & ADAM interop, in that ADAM does not populate the defaultNamingContext in RootDSE by default. The error shows that you connected to ADAM RootDSE, but without a search base, nothing gets exported.

Hasta luego,

-Russell “SpaniardR2” Despain