KB
No new DS-related KBs this week.
Blogs
Ned here. Mike Stephens has a short editorial on the GP development team blog. It addresses the fallacy of group policy "best practices" and is a good read for philosophy majors as well as IT staff. Here's a snippet:
"Yes, there might be settings common to “locking down a computer”, but what does “locking down” mean? Everyone is likely to have a different answer.
Read the rest and leave some comments.
- Ned "Descartes" Pyle
Hi all, Ned here again. Today I will share some recent questions we’ve gotten offline that never ended up as full blown blog posts. Naturally any names have been changed to protect the innocent and things are often paraphrased. This post starts a new series that will appear every Friday, barring some kind of disaster such as me being out sick, me taking the day off, or me just not feeling like it (so nyyyaaahhh).
Onward.
Question:
Is there any risk running Windows disk defrag on a DC? I need to defrag my drives and I’m worried about NTDS.DIT corruption.
Answer:
Nothing to worry about. In fact, starting in Windows Server 2008 and continuing in R2, you have been running a disk defrag every Wednesday at 1 AM whether you knew it or not. This is default behavior, even on domain controllers.
Note that the task is designed to run in idle state though, so if things stay really busy on a DC all night long, the automatic defrag may be preempted. The Task Scheduler Help has more info on what “Idle” means.
Question:
When I search AD for old computer accounts by using the whenChanged attribute that computers seem to be constantly “new”. How can I find old unused computer accounts using PowerShell?
Answer:
The attribute you want to use in this scenario is lastLogonTimeStamp; Warren wrote up a pretty comprehensive treatise in this older post. You can search for these inactive accounts using things like AD PowerShell’s cmdlet search-adaccount. For example, this would find all computers in the domain that have not logged into AD in a year:
Search-ADaccount -AccountInactive -Timespan 365 -ComputersOnly
Avoid looking at stale passwords, as password changes can be disabled. And before acting upon inactive accounts, make triple sure it’s really inactive. Cluster virtual computer objects don’t necessarily “logon” but if you arbitrarily get rid of them there will be heck to pay. Automating the removal is generally a bad idea.
Question:
I am trying to use the Delegate Control wizard within DSA.MSC. When I use a custom task delegation for User Objects I can’t specify certain attributes like Office, E-Mail, City, State, or Country. How can I get these?
Answer:
Choose the inetOrgPerson object class instead of User – this will get you the granularity you need with the delegation wizard. Chalk this up to vagaries of snap-in, schema, class, and inheritance.
Question:
Application X doesn’t seem to work correctly with Read-Only Domain Controllers, and I am not finding anything online that says it is compatible. What should I do?
Answer:
Find out who created that application and talk to their support staff. If it’s a Microsoft application or Windows component, open a support case and ask to speak that particular specialty. If not MS, call that vendor. If internal to your company, find that developer! There’s no way for the AD developers test everything against RODC’s – not even within the MS-developed gamut of applications, which is huge. They have to rely on application developers to add it to their test harnesses. If the conversation with the vendor starts with “What’s an RODC?”, they probably don’t test it. :)
No matter who you talk to, once it’s established that an RODC is or isn’t supported, make them document it publically; even if it’s just a blog post, you are helping out your fellow IT humans.
Question:
Hey, I think I found an error in KB article Y. Can you fix it?
Answer:
You betcha. Just tell us exactly what you think is wrong, making sure to give us repro steps. If we confirm it as factual error the KB should be corrected within a few weeks. If it comes down to semantics or a difference of opinion…well, as my wife says “we’ll just have to agree to disagree” (i.e. Ned is wrong, Lisa is right, and there’s nothing Ned can do about it).
Question:
I need some deeper support than this blog is set up for and time is not an issue, but I am a bit strapped for cash. Is there anywhere reputable I can go?
Answer:
Our community forums are an excellent place to ask deeper specific questions. These are moderated by MS support engineers and MVP’s. Many questions can be answered quickly and reliably by trustworthy folks.
If time and live support is critical though, open a support case. Time is money.
I reckon that’s enough for today. Have a nice weekend folks.
- Ned ‘going postal’ Pyle
Hi, Ned here again. Have you ever had to figure out what operating systems are running in your domain environment so that you can plan for upgrades, service pack updates, or support lifecycle transitions? Did you know that you don’t have to connect to any of the computers to find out? It’s easier than you might think, and all possible once you start using AD PowerShell in Windows Server 2008 R2 or Windows 7 with RSAT.
Get-ADComputer
The cmdlet of choice for inventorying computers through AD is Get-ADComputer. This command automatically searches for computer objects throughout a domain, returning all sorts of info.
As I have written about previously my first step is to fire up PowerShell and import the ActiveDirectory module:
Then if I want to see all the details about using this cmdlet, I run:
Get-Help Get-ADComputer -Full
Getting OS information
Basics
Now I want to pull some data from my domain. I start by running the following:
Important note: in all my samples below, the lines are wrapped for readability.
Another important note (thanks dloder): I am going for simplicity and introduction here, so the -Filter and -Property switches are not designed for perfect efficiency. As you get comfortable with AD PowerShell, I highly recommend that you start tuning for less data to be returned - the "filter left, format right" model described here by Don Jones.
Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto
This command is filtering all computers for all their properties. It then feeds the data (using that pipe symbol) into a formatted table. The only attributes that the table contains are the computer name, operating system description, service pack, and OS version. It also automatically sizes and wraps the data. When run, I see:
It looks like I have some work to do here – one Windows Server 2003 computer needs Service Pack 2 installed ASAP. And I still have a Windows 2000 server that is going to move quickly and replace that server.
Server Filtering
Now I start breaking down the results with filters. I run:
Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto
I have changed my filter to find all the computers that are running “Windows Server something”, using the –like filter. And I stopped displaying the OS version data because it was not providing me anything unique (yet!).
Cool, now only servers are listed! But wait… where’d my Windows 2000 server go? Ahhhh… sneaky. We didn’t start calling OS’s “Windows Server” until 2003. Before that it was “Windows 2000 Server”. I need to massage my filter a bit:
Get-ADComputer -Filter {OperatingSystem -Like "Windows *Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto
See the difference? I just added an extra asterisk to surround “Server”.
As you can see, my environment has a variety of Windows server versions running. I’m interested in the ones that are running Windows Server 2008 or Windows Server 2008 R2. And once I have that, I might just want to see the R2 servers – I have an upcoming DFSR clustering project that requires some R2 computers. I run these two sets of commands:
Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*2008*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto
Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*r2*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto
Starting to make sense? Repetition is key; hopefully you are following along with your own servers.
Workstation Filtering
Okeydokey, I think I’ve got all I need to know about servers – now what about all those workstations? I will simply switch from -Like to -Notlike with my previous server query:
Get-ADComputer -Filter {OperatingSystem -NotLike "*server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto
And blammo:
Family filtering
By now these filters should be making more sense and PowerShell is looking less scary. Let’s say I want to filter by the “family” of operating system. This can be useful when trying to identify computers that started having a special capability in one OS release and all subsequent releases, and where I don’t care about it being server or workstation. An example of that would be BitLocker – it only works on Windows Vista, Windows Server 2008, and later. I run:
Get-ADComputer -Filter {OperatingSystemVersion -ge "6"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto
See the change? I am now filtering on operating system version, to be equal to or greater than 6. This means that any computers that have a kernel version of 6 (Vista and 2008) or higher will be returned:
If I just wanted my Windows Server 2008 R2 and Windows 7 family of computers, I can change my filter slightly:
Get-ADComputer -Filter {OperatingSystemVersion -ge "6.1"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto
Getting it all into a file
So what we’ve done ‘til now was just use PowerShell to send goo out to the screen and stare. In all but the smallest domains, though, this will soon get unreadable. I need a way to send all this out to a text file for easier sorting, filtering, and analysis.
This is where Export-CSV comes in. With the chaining of an additional pipeline I can find all the computers, select the attributes I find valuable for them, then send them into a comma-separated text file that is even able to read the weirdo UTF-8 trademark characters that lawyers sometimes make us put in AD.
Hey, what do you call a million lawyers at the bottom of the ocean? A good start! Why don’t sharks eat lawyers? Professional courtesy! What do have when a lawyer is buried up to his neck in sand? Not enough sand! Haw haw… anyway:
Get-ADComputer -Filter * -Property * | Select-Object Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | Export-CSV AllWindows.csv -NoTypeInformation -Encoding UTF8
Then I just crack open the AllWindows.CSV file in Excel and:
What about the whole forest?
You may be tempted to take some of the commands above and tack on the necessary arguments to search the entire forest. This means adding:
-searchbase “” –server <domain FQDN>:3268
That way you wouldn’t have to connect to a DC in every domain for the info – instead you’d just ask a single GC. Unfortunately, this won’t work; none of the operating system attributes are replicated by global catalog servers. Oh well, that’s not PowerShell’s fault. All the data must be pulled from domains individually, but that can be automated – I leave that to you as a learning exercise.
Conclusion
The point I made above about support lifecycle is no joke: 2010 is a very important year for a lot of Windows products’ support:
Hopefully these simple PowerShell commands make hunting down computers a bit easier for you.
Until next time.
- Ned “bird dog” Pyle
KB
| 977357 | A memory leak issue occurs in the Windows Management Instrumentation service on a computer that is running Windows Server 2008 R2 or Windows 7 |
| 979384 | The application directory partition is not removed from the replication scope in a Windows Server 2003-based domain or in a Windows Server 2008-based domain |
| 979601 | The SSL certificate is still bound to port 443 after you disable the WinRM HTTPS compatibility listener |
Blogs
Hey everyone, Rob here again. With the release of Windows Server 2008 R2 and Windows 7 we have added new methods of enrolling for certificates: Certificate Enrollment Policy (CEP) and Certificate Enrollment Service (CES). CEP is a web service that enables users and computers to obtain certificate enrollment policy information. This information includes what types of certificates can be requested and which CAs can issue them. CES is another web service that allows users and computers to perform certificate enrollment by using the HTTPS protocol. Together with the CEP web service, CES enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain. CEP/CES also enables cross-forest policy-based certificate enrollment for Windows 7 or Windows Server 2008 R2 clients.
Certificate enrollment without CEP / CES
Prior to Windows 7 and Windows Server 2008 R2 the client requesting a certificate requires network access to a domain controller and the Certification Authority (CA).
Here is a high level description of the process that is used:
Figure 1 - legacy certificate enrollment
Step 1. LDAP queries to a domain controller for a list of templates and enterprise CA’s.
The client computer does several LDAP queries to a local domain controller to get the following:
- Queries for a list of pKICertificateTemplate objects (Certificate Templates) within the forest.
- Queries for a list of pKIEnrollmentService objects (Enterprise CA’s) within the forest.
- Queries for a list of msPKI-Enterprise-Oid objects within the forest.
Once all of objects are returned to the client, it determines what Enterprise CA’s are available, and what certificate templates can be issued by each one of them. The client then determines the certificate templates for which it has permissions to enroll or autoenroll. If you are enrolling for certificates via the certificates snap-in it will display this list of available templates to the user.
Step 2. DCOM connection an Enterprise Certification Authority.
Once the client selects the certificate template for which to enroll, a DCOM connection is made to the CA. DCOM connects to the CertSrv Request DCOM interface to enroll for the certificate. The certificate is then handed back to the client.
You may be thinking at this point “how does it work with the Web Enrollment pages?”
Certificate web enrollment behaves in nearly the same way. The main difference is that in Figure 1 the web server running the CertSrv web pages would replace the Client. The actual Client communicates with the web enrollment pages over HTTP, so the web enrollment pages are acting as a proxy, querying Active Directory for a list of templates and converting the client’s HTTP based certificate request into a DCOM-based request that can be sent along to the CA.
As you can see the client has to have direct network connectivity to a domain controller and the Certification Authority to be able to enroll for certificates. With this as a requirement here are a few examples of where enrollment would fail:
- Internet based clients that need to enroll for a certificate or renew a certificate.
- Computers in a DMZ network. Typically computers in a DMZ do not have access to internal corporate resources like domain controllers and CA’s because either they are in a workgroup or they belong to a DMZ forest with a one way trust in place.
- Non-domain joined workstations. They are unable to authenticate to a DC and perform the initial LDAP queries, and thus will never make it to step 2 - the RPC / DCOM call.
Certificate enrollment with CEP / CES
We listened to feedback from customers about the above limitations of enrolling for certificates. Our answer was to create two new web services to proxy the enrollment requests. This allows for CA isolation and removes the requirement that the client be able to contact a domain controller or CA directly.
These new roles are only available on Windows Server 2008 R2 and the only clients that are capable of requesting certificates via CEP and CES is Windows 7 and Windows Server 2008 R2. However the roles can be used with Windows Server 2003, 2008, and 2008R2 Certification Authorities (CA).
Figure 2 - CEP / CES certificate enrollment
NOTE: The CEP and CES web services can be installed on the same server or, as Figure 2 shows, installed on two separate servers.
Step 1. Client connects to the CEP web service over HTTPS.
The Windows 7 / Windows Server 2008R2 computer is configured to enroll for certificates against a CEP server. When a CEP server is configured in the environment the client will connect to the CEP server via port 443 (HTTPS), and connect to the CEP web service.
Administrators can configure via local / group policy what CEP server to use at the following locations:
Computer Configuration\Policies\Windows Settings\Security Policy\Public Key Policies\Certificate Services Client – Certificate Enrollment Policy
User Configuration\Policies\Windows Settings\ Security Policy\Public Key Policies\Certificate Services Client – Certificate Enrollment Policy
Step 2. – CEP web service queries LDAP.
The CEP service will send an LDAP query to a domain controller to get the following:
- Queries for a list of pKICertificateTemplate objects (Certificate Templates) within the forest.
- Queries for a list of pKIEnrollmentService objects (Enterprise CA’s) within the forest.
- Queries for a list of msPKI-Enterprise-Oid objects within the forest.
Once all the objects are collected and sent back to the client computer it determines the types of certificate for which it can enroll and which enterprise CAs can issue those certificates. There is a new attribute on the CA’s pKIEnrollmentService object that tells the client computer what the URI’s are for the CES servers in the environment. The attribute name is msPKI-Enrollment-Servers. The attribute is a multi-valued string so there can be multiple URI’s defined if you need to support different authentication methods. More on that later.
Step 3. Client connects to the CES web service over HTTPS.
The client then connects to the CES web service that answers for the Certification Authority that is configured to issue the certificate. The actual CES URI is defined in the msPKI-Enrollment-Servers attribute on the pKIEnrollmentService object for that CA.
Step 4. CES web service impersonates the client security context to request a certificate via DCOM, and then hands the certificate back to the client.
Here are some common questions and answers around CEP / CES:
1. If I have Windows 7 or Windows Server 2008R2 are either CEP and CES required for certificate requests?
If the Windows 7 / 2008R2 computer exists in the same Active Directory forest as the CA, then no. If you do not install the new roles Windows 7/2008R2 can still request certificates in the way that legacy clients do (Figure 1). Just like those legacy clients, however, Windows 7/ 2008R2 clients will need network connectivity to a domain controller and the CA.
2. When would CEP / CES be a good solution for my environment?
CEP / CES should be used in the environment when you require any of the following:
- Windows 7/2008R2 internet based clients need to be able to enroll for certificates.
- Windows 7 / 2008R2 based clients in another forest need to enroll for certificates against a 2008R2 CA in a separate forest.
- There is a requirement that client computers should not be able to access the CA directly over the network, or there is a Firewall between the CA and client computer and your clients are Windows7 /2008R2.
3. Where can the CEP / CES roles be installed?
- The roles can be installed on the CA, but that would defeats the purpose since the client will still need network connectivity to the CA.
- The roles can be installed on a domain member. The domain member could be on the internal network, or possibly in a DMZ. Please keep in mind that the CES role will require Kerberos delegation to be configured because it impersonates the user to the CA DCOM interface.
- The roles can be installed on the same computer or on separate computers. Please keep in mind that the CES role will require Kerberos delegation to be configured because it impersonates the user to the CA DCOM interface.
- Multiple instances of the CES web service can be installed on the same server. This allows you to increase the availability of the web service in environments with a large number of clients.
I hope that you have been able to learn a little more about these two new roles available on Windows Server 2008R2, and how to determine if you need to install and configure them. If you want more detailed information on CEP and CES you can review the Certificate Enrollment Web Services whitepaper.
Rob “minty” Greene
I have a teammate with too much time, money and Ebay expertise on his hands. So I am now a luchador.
In other news, our holiday posting drought should be at an end – plenty of blog stuff in the pipeline coming your way soon. Stay tuned.
- Ned “corto y el mal” Pyle
David Everett here again with an interesting issue that causes the Advertising test in DCdiag.exe to fail when verifying the role of a global catalog (GC).
A customer called Microsoft Product Support to determine why the Advertising test in dcdiag.exe was reporting that the global catalog role was not working on a Windows Server 2008 Read-only domain controller (RODC) when all other indicators suggested it was functioning normally. DCDiag.exe reported the DC was advertising as a GC but DCDiag couldn’t perform a search against the GC when the command was issued local to the server or remotely:
Dcdiag /test:advertising /v /s:RODC
<..snip..>
Doing primary tests
Testing server: SITEZ\RODC01
Starting test: Advertising
The DC RODC01 is advertising itself as a DC and having a DS.
The DC RODC01 is advertising as an LDAP server
The DC RODC01 is not advertising as having a writeable directory because it is an RODC
The DC RODC01 is advertising as a Key Distribution Center
The DC RODC01 is advertising as a time server
Ldap search capabality attribute search failed on server RODC01,
return value = 81
Server RODC01 is advertising as a global catalog, but
it could not be verified that the server thought it was a GC.
......................... RODC01 failed test Advertising
Determine the health of the Global Catalog
There are some simple tests that can be done to verify the DC is advertising the Global Catalog role. First, make a connection to the W2K8 DC's ROOTDSE over port 389 or 3268 to determine if the DC has sourced and is advertising the global catalog:
isGlobalCatalogReady: TRUE;
isSynchronized: TRUE;
Another useful test to verify the DC is advertising as a GC is to use the /GC parameter in nltest.exe and observe that GC is listed in the Flags:
nltest /dsgetdc:contoso /force /gc
DC: \\RODC01
Address: \\11.11.11.25
Dom Guid: a238ef59-eeef-11d2-a123-00805f9f123
Dom Name: CONTOSO
Forest Name: contoso.com
Dc Site Name: SITEX
Our Site Name: SITEX
Flags: GC DS LDAP KDC TIMESERV DNS_FOREST CLOSE_SITE PARTIAL_SECRET
The command completed successfully
The first two tests essentially confirm what dcdiag.exe already reports, namely that the server is advertising as a GC. The real question now is, “Do LDAP searches correctly retrieve objects from the global catalog?” Since the DC resides in contoso.com (the forest root domain) the search should be made to query an object from a different domain in the same forest over global catalog LDAP port 3268. The example below shows the GC successfully returns the child domain’s Administrator account:
repadmin.exe /showattr RODC01 “DC=child,DC=contoso,DC=com” /subtree /filter:“(&(objectClass=user)(name=Administrator))” /atts:name /gc
DN: CN=Administrator,CN=users,DC=child,DC=contoso,DC=com
1> name: Administrator
Understanding why LDAP search in the Advertising test is failing
This problem occurs when an administrator removes a domain controller machine account using adsiedit.msc but fails to remove the objects from the Configuration partition and then promotes a new DC with the same name into a different site.
Apparently an RODC account was pre-created in the wrong Active Directory site using the Pre-created Read-only Domain Controller account... option in DSA.MSC. The Active Directory Promotion Wizard prompts the administrator to type the hostname and select the Site where the prospective DC will reside. The wizard uses this information to create the computer account and its corresponding NTDS Settings object. At some point, the unoccupied RODC machine account was deleted from the Domain Controllers OU using adsiedit.msc but its corresponding NTDS Settings object was left in the Configuration partition. Eventually the server was promoted as a DC into the correct site and successfully promoted to be a GC.
It’s important to note that this condition isn’t specific to RODCs. The same issue occurs if a writable DC is removed from metadata in the same way and a server with the same name is later promoted into a different site.
All NTDS Settings objects have a parent server object named after the DC. This parent server object contains a dNSHostName attribute that is populated with the fully qualified domain name of the DC. In this case the identically named stale and valid NTDS Settings objects in different sites have a dNSHostName attribute with the same FQDN.
The DCDIAG Advertising test searches the CN=Sites,CN=Configuration,DC=Contoso,DC=Com container for a Server object whose dNSHostName attribute matches the fully qualified computer name of the DC being targeted. Once it finds the object with the matching dNSHostname it retrieves the objectGUID of the subordinate NTDS Settings object and attempts to contact the target domain controller by its fully qualified CNAME which would normally be registered under the DNS zone “_msdcs.contoso.com”.
If DCDIAG discovers a Server object whose dNSHostName attribute matches the targeted DC but the ObjectGUID on the subordinate NTDS Settings object wasn't created by the last DCPROMO promotion or machine account pre-creation, then the LDAP bind to the targeted DC will fail with LDAP error 81. To get a better understanding of what this error means, download Err.exe and pass it the error code and you find it translates to "LDAP_SERVER_DOWN".
Identify Valid and Invalid NTDS Settings objects and clean up
1. Determine the DSA object GUID and Site name that the DC is currently registering in DNS as a CNAME record by running this command:
C:\>repadmin /showreps <name of dc> |more
<AD Site Name>\RODC01
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 52399da1-87ba-4da6-bce3-71dcf0d85f34
DSA invocationID: 18bce5ac-d9f4-46dc-bccf-f3e39da103f9
2. Use the repadmin.exe command below to locate the Site that the invalid NTDS Settings object is in:
C:\>repadmin.exe /showattr RODC01 “CN=Sites,CN=Configuration,DC=contoso,DC=com” /subtree /filter:“(&(objectClass=server)(name=RODC01))” /atts:name
DN: CN=RODC01,CN=Servers,CN=SITE-A,CN=Sites,DC=Configuration,DC=contoso,DC=com
1> name: RODC01
DN: CN=RODC01,CN=Servers,CN=SITE-Z,CN=Sites,DC=Configuration,DC=contoso,DC=com
1> name: RODC01
3. Verify the wrong server object in the undesirable site is causing the failure:
a. Open adsiedit.msc and view the Properties of the invalid Server object.
b. Select the Attribute Editor tab and Edit the dNSHostName attribute.
c. Click Clear, OK and Apply to remove the FQDN of the RODC from the invalid object.
d. Once AD replication of this change makes it to the RODC run:
dcdiag /test:advertising /v /s:RODC01
e. Verify the DC is now advertising as a GC.
4. Now that DCdiag is free of errors delete the invalid server object using the preferred method of metadata cleanup.
a. Right-click the NTDS Settings object of the invalid RODC in Active Directory Sites and Services and select Delete
b. Click Yes at the Active Directory Domain Services prompt to delete the NTDS Settings object
c. Uncheck all three boxes in the Deleting Domain Controller window and click Delete
d. Once the subordinate NTDS Settings object has been removed, delete the invalid server object that is just superior to the NTDS Settings object that was just deleted.
NOTE: Because the serverReference attribute is NULL on the invalid NTDS Settings object the corresponding DC object in the domain partition will not be removed.
One way to ensure you never encounter this issue with dcdiag.exe is to start using this last step to remove a domain controller from the metadata instead of adsiedit.msc.
David “Mad Men” Everett
KB
| 978155 | A memory leak occurs when an ADO Recordset object calls the UpdateBatch method |
| 976779 | Windows Automation API 3.0 release notes |
| 977211 | The DFS Replication service exits unexpectedly on a computer that is running Windows Server 2003 R2 SP2 |
| 977692 | The Lsass.exe process exits unexpectedly on a domain controller that is running Windows Server 2008 R2 after a password is synchronized in Identity Management for Unix (IDMU) |
| 979281 | Error code 0x80070002 when backing up files in Windows 7 |
| 978042 | FIX: A memory leak may occur when you use the Microsoft ActiveX Data Objects Library in Windows Vista, in Windows 7, in Windows Server 2008, or in Windows Server 2008 R2 |
| 977686 | The Licensing Diagnosis tool incorrectly reports that there are no available Terminal Services client access licenses in Windows Server 2008 |
| 978538 | The DFS Replication service crashes randomly in Windows Server 2008 |
| 979682 | Microsoft Security Advisory: Vulnerability in Windows Kernel could allow elevation of privilege |
Blogs
Hi all, Ned here again. We’ve gotten word that the SCOM 2007 management pack for file services has reached beta and is available to the public on our Connect site. Here’s the info:
Overview
The File Services Team is proud to announce the beta release of our File Services Management Pack for System Center Operations Manager 2007. This management pack provides health monitoring for SMB shares, NFS shares, DFS Namespaces, DFS Replication and File Server Resource Manager including the File Classification Infrastructure.
Supported OS Versions
The following table describes which File Services role service can be monitored with the beta management pack on various Windows Server versions:
|
Role Service |
OS Version Supported |
|
DFS Namespaces |
Windows Server 2003, 2003 R2, 2008, 2008 R2 |
|
DFS Replication |
Windows Server 2003 R2, 2008, 2008 R2 |
|
File Classification Infrastructure |
Windows Server 2008 R2 |
|
File Server Resource Manager |
Windows Server 2008 R2 |
|
NFS File Sharing |
Windows Server 2008 R2 |
|
SMB File Sharing |
Windows Server 2008 R2 |
New Features
The table below describes several of the key features provided in this beta management pack:
|
Feature |
Description |
|
Agentless Monitoring |
Ability to monitor file services on servers without deploying a SCOM agent to the specific server |
|
Highly Available Cluster Instance Monitoring |
Ability to monitor the health status of a Highly Available File Server deployed on a Failover Cluster |
|
NFS Role Service |
Monitor activity logging, NIS configuration, port registration, portmaper service, NFS service driver, username mapping service, and more |
|
FSRM Role Service |
Monitor FSRM service, quota driver, filescreen driver, file classification task progress, and orphaned mountpoints |
|
DFSR Role Service |
Monitor the health of DFS Replication service, communications with replication partners, database recovery, communications with Domain Controllers, free space on volume containing a replicated folder, USN journal wrap events, overlap with FRS, inconsistent configuration, and more |
|
DFSR Backlog Tracking |
Ability to display the backlog count per connection for a DFS replication group |
|
DFSR Performance Counters |
Track data for bandwidth ravings, replication conflicts, deleted files and staging area |
|
DFS Namespace Role Service |
Monitor DFS namespace service, health of a single namespace hosted on multiple servers, health of the AD component of DFS namespaces, site table initialization, namespace initialization, Namespace Synchronization with AD, Folder Target Health and more |
|
SMB Role Service |
Monitor the health of Lanman server service, creation of shares at system startup, IRP stack overflow events, firewall port configuration |
Download Instructions
- Log on to Microsoft Connect and create a profile if you have not already created a profile
- Navigate to Connection Directory
- Search for File Services and Storage and select Apply Now
- Fill-out application survey
- Log on to File Services and Storage connection
- Click the announcement: Beta release of SCOM Management Pack for File Services in Server 2008 R2
- Follow instructions to download the Management Pack
Feedback Instructions
Submit feedback through the connection [Ned: and not through AskDS! Remember, Beta means not supported – this is for testing].
- Ned “press agent” Pyle
KB
| 977983 | Group Policy preferences client-side extension hotfix rollup for Windows Vista |
| 971357 | User password is set to NULL when you use Group Policy Preferences to create a user account |
Blogs
Hello, David Everett here again. Recently a customer contacted Microsoft Product Support to determine why the Connect to Domain Controller option in Active Directory Users and Computers (aka: ADUC or dsa.msc) was generating an incomplete list of Domain Controllers (DCs) for one domain. Even though the list of available DCs was truncated we found we could manually enter the name of any DC not in the list and Active Directory Users and Computers would connect to the DC without issue.
Determining the scope of the issue:
Wanting to see if the truncated list of DCs was specific to Active Directory Users and Computers or if other tools also failed to locate all the DCs we ran nltest.exe /dclist:contoso.com. The output shown below revealed a complete list of domain controllers for contoso.com but many were missing their [DS] Site: information. We found that those DCs missing their [DS] Site: information happened to be the same DCs missing when Connect to Domain Controller was selected. One final observation was that the list of available DCs varied from one DC to the next when selecting Connect to Domain Controller.
Get list of DCs in domain 'contoso.com' from '\\dc01.contoso.com '.
MAYDC01.contoso.com [DS] Site: Mayberry
MAYDC02.contoso.com [DS] Site: Mayberry
DALDC01.contoso.com [DS] Site: Dallas
DALDC02.contoso.com
LADC01.contoso.com [DS] Site: LosAngeles
LADC02.contoso.com
SEADC01.contoso.com
SEADC02.contoso.com
The two DCs in the Los Angeles site saw themselves in the list of available DCs but not the other DC in the same site. Suspecting Active Directory (AD) replication might be at fault we ran Repadmin /showrepl * /csv > Showrepl.csv and found AD replication was free of errors forest wide.
Checking for Database Inconsistencies:
Since AD Replication was not at fault our focus switched to AD database inconsistencies. We focused on three primary objects which house all of the metadata needed for DC discovery:
- The Distinguished Name (DN) of the DC’s object in the domain partition
CN=LADC01,OU=Domain Controllers,DC=contoso,DC=com
- The DN of the DC’s NTDS Settings object and
CN=NTDS Settings,CN=LADC01,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com
- The DN of the DC’s Server object which resides just above the DC’s NTDS Settings object in the Configuration partition
CN=LADC01,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com
Using LDP.EXE we connected to both DCs in the Los Angeles site and gathered dumps of all three objects for both DCs and compared the output. For those who tend to avoid this tool, see MSKB 252335 on how to Bind and Connect but make certain to select CN=Configuration,DC=forestrootdomain from the Base DN: drop-down. Expand the configuration partition on the left until you locate the server object of the DC that was restored.
This LDP dump of LADC01’s Server object in the Configuration partition was taken while bound to LADC01 (notice the DC name in blue title bar indicating which DC we’re bound to). Looking at the third attribute from the bottom we find the serverReference forward link attribute in the list of attributes. This attribute contains the DN path of the corresponding DC object in the DC=contoso,DC=com partition. Below is an LDP dump of LADC01’s Server object while bound to LADC02. Notice the serverReference forward link attribute is missing which indicates it is not populated on this DC’s copy of the AD Database.
When we examined the LDP dumps of LADC02’s Server object we found the same was true. LADC02 had a DN for its own DC object but the LDP dump of LADC02’s Server object taken while bound to LADC01 had an empty serverReference attribute. Finally, those DCs which always appear in the list of domain controllers had a populated serverReference attribute on all DCs.
To determine how widespread this issue was we queried the serverReference attribute for both Los Angeles DCs from every DC in the forest using the repadmin /showattr command below. DCs that returned a serverReference attribute had the DC object DN and those DCs that had no serverReference attribute were empty:
Repadmin.exe /showattr * CN=LADC01,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com /atts:serverReference
Fixing the problem:
We connected to the configuration partition on LADC01 using adsiedit.msc and manually added the “CN=LADC02,OU=Domain Controllers,DC=contoso,DC=com” DN to the serverReference attribute on LADC02. This change made LADC02 appear in the list of available DCs when the Connect to Domain Controller option was selected in Active Directory Users and Computers. Also, nltest.exe /dclist:contoso.com now showed [DS] Site: LosAngeles next to LADC02.contoso.com on all DCs. Not shown here, but once the DN of the DC’s object in the contoso.com domain was added to the serverReference attribute, the serverReferenceBL back-link attribute was automatically populated on the DC object in the contoso.com domain.
Determining how this occurred:
Now that we understood why the DC list was incomplete we started looking for how this occurred. To do this we gathered replication metadata from these three objects for both LADC01 and LADC02. The command used to gather the metadata from LADC01 for LADC02’s server object in the configuration partition is:
repadmin.exe /showobjmeta LADC01 CN=LADC02,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com
Comparing the objects dumped from LADC01 and LADC02 we found the Ver (version) numbers matched. It wasn’t until we looked at metadata of the DC object in the domain partition and compared it with the corresponding Server object in the configuration partition that we understood what occurred.
Here is a showobjmeta dump of CN=LADC02,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com from LADC01:
repadmin.exe /showobjmeta ladc01 CN=LADC02,CN=Servers,CN=LosAngeles,CN=Sites,CN=Configuration,DC=contoso,DC=com
11 entries.
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= ============ === ====== ============= === =========
8363 b5c14a75-7f99-4f31-b84b-d755190a2c0d 213256008 2007-04-15 15:04:39 1 objectClass
85895 LosAngeles\LADC02 85895 2007-04-15 17:11:27 2 cn
8363 b5c14a75-7f99-4f31-b84b-d755190a2c0d 213256008 2007-04-15 15:04:39 1 instanceType
8363 b5c14a75-7f99-4f31-b84b-d755190a2c0d 213256008 2007-04-15 15:04:39 1 whenCreated
<snip>
Here is a truncated showobjmeta dump of CN=LADC02,OU=Domain Controllers,DC=contoso,DC=com from LADC01:
repadmin.exe /showobjmeta ladc01 CN=LADC02,OU=Domain Controllers,DC=contoso,DC=com
41 entries.
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= ============ === ======== ============= === =========
92248340 fb36d148-19fd-43f0-8876-91a027863f79 155898 2009-11-18 12:56:34 100001 objectClass
92248339 77dba4f6-3870-4eb5-b46a-4f1fb1ee0be6 92248339 2009-11-18 12:59:51 4 cn
92248340 fb36d148-19fd-43f0-8876-91a027863f79 155898 2009-11-18 12:56:34 100001 description
92248340 fb36d148-19fd-43f0-8876-91a027863f79 155898 2009-11-18 12:56:34 100001 instanceType
9027 4855f23c-744c-488d-852c-9c170dd3359c 108176481 2007-04-15 18:10:11 1 whenCreated
<snip>
Interpretation of the data:
The Version number of the attributes on LADC01’s DC object in the domain partition have a USN that is 100,000 higher than the DC’s corresponding Server object in the configuration partition. This strongly suggests the DC object in the Domain Controllers OU was authoritatively restored with the default version increase of 100,000 while the DC’s corresponding Server object in the configuration partition was not authoritatively restored. The customer then remembered accidentally deleting several of the DCs a while back and performing an authoritative restore on the entire Domain Controllers OU.
Understanding the inconsistencies:
Now that we knew an authoritative restore of the domain controllers OU was performed we needed to determine why the serverReference and serverReferenceBL attributes for restored DCs were missing and different across all DCs.
Anyone who has performed authoritative restores of users and groups will recall an issue where group membership is not correct on replica DCs after users and groups are authoritatively restored; this is discussed at length in KB280079. In the case of restored users and groups, when a user is deleted their membership from the remaining group is removed. If the user is then restored, but the group is not, the membership will not be restored on any DC except the DC where the restore took place. For those wondering what this has to do with DCs being restored, it is identical. DCs are security principals just like users, and the DC’s server object in the configuration partition behaves much like a group. If the DC object is deleted from the domain partition the serverReference attribute containing the forward link will be NULL’ed out on the server object in the configuration partition. If just the DC object in the domain partition is restored the serverReference attribute on the corresponding server object in the configuration partition will not be updated on replica DCs once the restored DC object inbound replicates to them.
Avoiding this issue:
Since the release of Windows Server 2003 Service Pack 1 ntdsutil.exe has automatically created LDF files for all partitions in the forest where restored objects have back-links. This is discussed further in MSKB 840001. In the case of user accounts you ensure all users have the correct group membership on all DCs by allowing the restored user accounts to replicate to all DCs/GCs. Once all DCs have the restored account you use ldifde -i -f <AR*.ldf> and import the user’s group membership against to the recovery DC. Doing this ensures the user’s DN is added to the member attribute on the group and the version of the member attribute is bumped higher causing it to replicate to all DCs. Since all DCs have a copy of the restored user account in their local database the DN on the member attribute is retained. As a rule of thumb, if you are authoritatively restoring users, computers or groups you should always import the LDF files created by ntdsutil.exe and avoid issues like this.
Or even better, deploy Windows Server 2008 R2 and enable the AD Recycle Bin – it automatically handles back links and forward links.
- Dave “metadata” Everett
Hi all Rob Greene here again. I thought I would share with you how to do some common tasks with a Windows Server 2008 clustered Certification Authority (CA). When the CA is clustered there are definitely different steps that need to be taken when you:
- Make a change to the behavior of the CA by using certutil.exe with –setreg or –delreg switches.
- Modify the registry values in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc hive.
- Renew the CA’s certificate.
In the past before the Certification Authority service (CertSvc) was supported in a cluster, you could make these changes and then stop and start the CertSvc service without a problem. This is still the case when the Certification Authority has not been clustered.
However, when you have the Certification Authority configured as a cluster you must avoid starting and stopping the service outside of the Cluster Administrator snap-in (Cluadmin.msc). The reason is that the Cluster Service not only keeps track of the service state for CertSvc, it is also responsible for making sure that the registry key location HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc is saved to the quorum disk when it notices a change to the registry location. This is noted in the CA Cluster whitepaper also, which is required reading for anyone clustering CA’s.
Changing the behavior of the Certification Authority
If you need to make a change to the behavior of the Certification Authority with CertUtil.exe or direct registry modification, you must always follow the steps below:
1. Logon to the active clustered Certification Authority node. If you are unsure which node currently owns the resource do the following:
a. Launch the failover Cluster Management MMC.
b. Select the Certification Authority resource, and in the right hand pane you will see the “Current Owner” (See figure 1).
Figure 1 - Current Owner of the Certification Authority resource
2. Use certutil.exe –setreg (recommended) command, or modify the registry directly.
3. Launch the Failover Cluster Management snap-in.
4. Take the Certification Authority resource (Service) offline and then bring it back online. We have to take the resource offline and back online since the CertSvc service will not read any registry key changes without being restarted, and as I stated above when the CA is clustered you should refrain from stopping and starting the CertSvc service directly.
a. Right click on the Certification Authority resource in the tree view pane.
b. Select either “Bring this service or application online” or “Take this service or application offline” (See figure 2).
Figure 2 - Taking the resource offline / online
Renewing the subordinate Certification Authority certificate
This section discusses the steps that need to be done when renewing a subordinate CA certificate. A Root certification authority shouldn’t be clustered and instead should be configured as an offline root.
Verify the request file location
When the CA certificate is renewed it will stop the CertSvc service to generate the certificate request file. The request file location and name is dictated by the following registry key:
HKEY_Local_Machine\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\RequestFileName
Before renewing the CA you will want to make sure that the registry key points to a valid file system path. If it is not, either the renewal will fail silently, or you might get the error “The system cannot find the file specified” when you attempt to renew the CA. If you have to change this value do the following on the active CA node:
1. certutil –setreg CA\RequestFileName “<File path and name>”. For example:
certutil –setreg CA\RequestFileName "c:\contoso_subCA1.req”
2. Take the resource offline and back online (See Figure 2 above).
Renewing the Certification Authority certificate
As noted earlier, if the CertSvc service is stopped or started outside of the Failover Cluster Management snap-in the cluster system is not aware of any changes that are done to the registry. Here is a high level process of what happens when a CA is renewed so that you can understand why the below steps are necessary on a clustered CA:
1. CertSvc service is stopped to generate the certificate request file. It reads the RequestFileName registry value to determine where and what the file name should be for the request file.
2. CertSvc service is started once the request file has been generated.
3. CertSvc service is stopped again to install the issued certificate from the CA.
4. The CACertHash registry value is updated to include the new CA certificate hash.
NOTE: NEVER DELETE OR MODIFY this registry value unless directed by Microsoft support. Modifying this registry key can cause the CA not to function properly or in some cases to not even start!
Here are the actual steps to renew the CA on a cluster.
1. Open the Failover Cluster Management snap-in.
2. “Pause” the inactive Certification Authority node. If you are unsure about which server is the active node see Figure 1.
a. Select the computer node in the Failover Cluster Management snap-in.
b. Right click on it select “Pause”.
Figure 3 - Pausing the inactive node
3. Once the inactive node is paused you can renew the CA’s certificate. Please review the following TechNet article to help with the process of actually getting the subordinate CA certificate renewed.
4. Once you have gotten the CA’s certificate renewed by the root CA, and installed the new certificate to the subordinate CA you will need to take the Certification Authority resource offline and then back online within the Failover Cluster Management snapin.
a. Right click on the Certification Authority resource in the tree view pane.
b. Select either “Bring this service or application online” or “Take this service or application offline” (See figure 2 above).
5. Open the Certification Authority snapin, and target the Clustered Network resource name.
6. Right click on the Certification Authority name and select properties.
7. If you renewed with a new key pair you should see several certificates listed as show in figure 4.
Figure 4 - Certification Authority properties.
8. Once you have verified that the Certification Authority is using the renewed CA certificate you can “Resume” the node that was paused in step 2.
Since the Certification Authority service is configured as a generic service the above processes must be adhered to when managing a clustered CA. If changes are made outside of the Cluster service’s knowledge then the nodes will never be in sync and clustering will fail
- Rob “Raaaahhb” Greene
KB
| 974841 | An update is available for Windows XP to support protocol negotiation for remote procedure call (RPC) over HTTP Authentication |
| 958147 | The Member ID field is logged incorrectly in the audit event on a Windows Server 2003 domain controller if you add a user of a different domain to a universal group |
| 955007 | The replication may seem like it is serialized when there are slow connections in a DFS Replication configuration in Windows Server 2003 R2 |
| 977624 | AD RMS clients cannot authenticate federated identity providers |
| 977269 | Error message when you make a remote desktop connection to a terminal server that is running Windows Server 2008: “The requested operation requires elevation” |
| 977381 | The DFS Replication service may stop responding when it initializes the replication process for the replicated folders on a computer that is running Windows Server 2008 or Windows Server 2008 R2 |
| 973243 | The default gateway is missing on a computer that is running Windows Server 2008 or Windows Vista after the computer restarts if the default gateway is set by using the Netsh command |
| 976674 | The computer stops responding when you access some shared files from a computer that is running Windows Server 2008 or Windows Vista |
| 975363 | A time-out error occurs when many NTLM authentication requests are sent from a computer that is running Windows Server 2008 R2 or Windows 7 in a high latency network |
| 978034 | Active Directory Certificate Services cannot be reinstalled by using the "Use existing private key" option on a computer that is running in Windows Server 2008 R2 |
| 978116 | In an MIT realm, user authentication fails after invalid credentials are received on a computer that is running Windows 7 or Windows Server 2008 R2 |
Blogs
Ned here again. I’m frequently asked to explain the DFSR conflict algorithm – i.e. what happens when files are created or modified on two servers before replication takes place. What we don’t document well is that there are actually three conflict algorithms and they all behave quite differently. I am breaking these out into scenarios for easier understanding.
Scenario 1: Brand new files in initial sync with different versions of the file on each server.
- Two servers, A and B
- Both have a folder called c:\rfdata
- Folder contains a file called salespitch.pptx
- On server A, salespitch.pptx is dated July 2009. On server B, salespitch.pptx is dated October 2009 and was modified by a user very recently.
- I setup a new Replication Group.
- I make c:\rfdata the Replicated Folder.
- I make Server A the Primary Server.
Result: salespitch.pptx from A (dated July 2009) will now exist on both servers. The October version will be conflicted on B and it will lose the conflict.
Explanation: When setting a server as Primary, it wins all conflicts no matter what. This is the so-called “Initial Sync conflict algorithm”.
Scenario 2: Existing files that have been replicated previously and are now being modified on two servers before replicating.
- Two servers, A and B
- Both are in an existing Replication Group (not performing initial sync) with a replicated folder pointing to c:\rfdata
- Folder contains a file called salespitch.pptx
- Replication is latent (in my test, I disconnected network cable from Server A)
- I modify the salespitch.pptx file on both servers. On Server A, I modified salespitch.pptx last.
- I plug the network cable back in to allow replication to resume.
Result: The file I modified last (i.e. the newest file with the latest UTC time stamp) replicates from A to B. B loses the conflict and his older copy will be conflicted.
Explanation: This is the classic “last writer wins conflict algorithm” that is usually described for DFSR.
Scenario 3: New files that were created on both servers before replicating, but initial sync is not happening
- Two servers, A and B
- Both are in a Replication Group with a replicated folder pointing to c:\rfdata
- Replication is latent (in my test, I disconnected network cable from Server A)
- I copy an old file to both server A and B – so this file is “new” to DFSR on both servers.
- I modify one file on server B.
- I plug the network cable back in on A.
Result: The old file on A is replicated to B, and B loses the conflict.
Explanation: This is the only time an older file will win, and this would be the so-called “New to DFSR file conflict algorithm”. The reasoning here would be that when it comes to two files being created, the oldest one is likely the most important as it has been in use the longest.
That’s all well and good. But how do I get my conflicted files back when the “wrong” one wins?
You have a few options here:
- Use DPM – Data Protection Manager provides on-the-fly backups of files and near-line recovery. This way your odds are highest that the latest versions of the file have been backed up.
- Use Volume Shadow Copies – You can configure automatic backups of files on your DFSR servers. Then when users delete or conflict files, the data can be easily restored. With a little training, your users can even restore files themselves and not have to spend time with the help desk. Note also that if you are still running XP or (Dog forbid) Win2000, you need to install a client to let users restore their own files. See TechNet and Windows Help for configuring this on a per-OS basis and make sure you read through the best practices info. VSC does not replace regular backups!
- Use backups – Windows Server Backup, NT Backup (if still on Win2003 R2), or 3rd parties should be used to back up
your data every day. This way no matter what, you can always get back to yesterday’s copy of a file.
- Use the restoredfsr.vbs script – Unsupported, as-is, and provided without warranty, this script may be your only hope if you have no created backups and shadow copies. Use it at your own risk. I have attached an updated copy to this blog post that handles a few more complex file scenarios. As always, the script requires you to edit a few variables before running – see the script for how-to documentation. You run it with:
CSCRIPT.EXE restoredfsr.vbs
Hopefully this makes more sense now.
- Ned “the mediator” Pyle
