March, 2010

Hi folks, Ned here again. This week we hunt down some documentation gremlins and give them a well-deserved smack.

Also, things will be a bit slow next week as I will be out in Redmond teaching this rotation of Microsoft Certified Masters. Never heard of it? If you’re at the IT career tipping point, this may be just what the doctor ordered. No really, it is, and I will be there!

• Dcdiag /fix
• DFSR RPC improvements in Win2008+
• USMT /SF

Question

What exactly does the dcdiag.exe /fix command do? According to this it fixes the SPNs on the DC machine account. But according to this it ensures that SRV records are appropriately registered (I thought the NetLogon service did this?!). And what exactly does the netdiag.exe /fix command do? This article says it "fixes minor problems", whatever that means.

Answer

1. Dcdiag /fix writes back the computers account’s AD replication SPN (DRSUAPI with an index value of “E3514235-4B06-11D1-AB04-00C04FC2DCD2”) entry only. More info on this SPN here:

http://msdn.microsoft.com/en-us/library/dd207876(PROT.13).aspx
http://msdn.microsoft.com/en-us/library/ee791539(PROT.10).aspx

If someone (else!) has destroyed all the other SPN’s, you will need to recreate them or restart whichever service recreates them. For example if the DFSR SPN goes missing, you restart the DFSR service and it will get put back.

2. Netdiag /fix reads the %systemroot%\system32\config\Netlogon.dns file and attempts to register all records in DNS.

I confirmed both in source code, regardless of what old TechNet goo states. :-)

Question

In Win2008 DFSR has been improved regarding the asynchronous RPC connections and 16 concurrent connections for upload and download. Do you have any further info on how improved the performance will be from Win2003 R2 to Win2008/2008 R2? Are there any other factors that would drive me to start rolling out the later OS versions?

Answer

I will be posting posted some new info about performance improvements in 2008/2008 R2 as well as registry tuning options in the coming weeks. But we don’t have any specific case studies that I am aware of yet – I’ll see if I can find them, and if you do, feel free to comment. We do have some rather unspecific ones, if you’re interested.

From testing and customer experience though, we see anywhere from a 4 to 20 times performance improvement of 2008 over 2003 R2, depending on a variety of factors that are often very customer specific (network speed, bandwidth, latency, loss rates, errors, overall uptime + memory + CPU + disk subsystem + drivers). Not only did DFSR improve, but the OS got improvements and it makes better use of newer hardware. Besides the RPC and other changes, Win2008 tweaks the DFSR credit manager, and 2008 R2 really improves it – much more evenly-distributed replication with greatly lowered chance of servers being starved by updates.

Other factors:

1. Win2003 enters extended support on July 13 2010. This means no further hotfixes that improve reliability or performance, and 5 years of crossed fingers until end of life.
2. You would now have the option on DC’s to switch to DFSR-enabled SYSVOL and no longer use FRS there.
3. If deploying 2008 R2, you would also gain read-only and cluster support, which is unavailable in 2003/2008.

Question

I am using your old blog post on making custom registry changes and…

Answer

Ewwwww… The only reason to use that old document is if you are still running Windows 2000 somewhere. Otherwise you should be busting out Group Policy Preferences and wowing your friends and family.

Oh, and really? You’re running Win2000? That’s very uncool of you…

Question

I am doing USMT migrations with /SF. What is that switch and why are my migrations absolutely busted to heck?

Answer

This one came in late last week and was so gnarly that it ended generating a whole blog post. Read more here. Sometimes your questions to us generate more than a Friday reply.

Good work, Internets!

– Ned “3 important rules” Pyle

Hi folks, Ned here again. Despite worries in our Comments sections, the Friday Mail Sack is GO. This week we cover some GP, some computer maintenance, and some really nice fans.

• Terminal Services shell desktop policies
• Disabling compromised computers

Question

I am deploying Terminal Servers [Don’t you mean Remote Desktop Services – MS Sales Borg] and I’d like to remove all the shell icons from the users’ desktop. You know, stuff like “My Documents”.

I’d also like a background wallpaper that is automatically set when users are logged into Terminal Server only, but that won’t affect them when they are just using their desktop computers. Can you hook me up?

Answer

You bet.

To block all desktop icons in all versions of Windows, you can use the “Hide and disable all items on the desktop” group policy. This is stored in User configuration\<policies>\administrative templates\desktop.

You can also turn off specific shell icons on an individual basis via this set of policies, using things like “Remove Computer icon on the desktop”. And that desktop wallpaper setting is in here, under the second Desktop node.

Windows 7 and Windows Server 2008 R2 also introduce a new and highly customizable policy of “Disable Known Folders”, which is under User configuration\<policies>\administrative templates\windows components\windows explorer. This new policy lets you specify any kind of known shell folder you like, by name or GUID. Fancy schmancy!

Finally, if you want all this to apply to users only when they are logged into Terminal Servers [Don’t make me assimilate you! – MS Sales Borg] but not their desktops, you need to deploy Loopback Policy Processing. Good reading on this here:

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

http://technet.microsoft.com/en-us/library/cc780733(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc782810(WS.10).aspx

Question

We are trying to remove inactive computers from Active Directory. We have discovered through testing that disabled computer accounts still allow access to domain resources when a user logs in with cached credentials.

How can I be sure a user who logs on to a computer that has been disabled cannot access the domain using cached credentials?  I do need to allow cached credentials for our mobile users and I need to allow logging on with cached credentials in the case of a WAN outage for our desktops. 

Answer

How are the computers truly inactive if users are still logging on to them while accessing the corporate network? :-)

If you set the client computer account to disabled and then restart the client computer, it never lets anyone logon with cached domain credentials again.

XP example:

Without a restart the computer would continue to allow interactive domain logon for up to 10 hours, since it has a cached Kerberos ticket. The user will have his own Kerberos tickets as soon as he tries to access remote resources too.

I have a couple solutions here, and they also cover where you no longer trust a computer and just want it gone:

• You could audit for Logon/Logoff events. In Win2003 these would be event 540 on the DC, and would include the computer name and IP address. If you had just zapped a bunch of clients for being inactive, you could monitor this log on DC’s for any computers you know are now disabled then use the IP info to locate the computers physically and confiscate them. In Win2008 that would be event 4624.
• If the computer is still online and you know its local administrator password, you could disable the computer account in AD and force that to replicate. Then you could send the remote shutdown.exe command to boot the client – once it comes back up it’s not going anywhere, nor are any domain users.
• You could use IPSEC. When you had computers that you wanted to ban from the network, you would simply revoke their computer certificate centrally and deny them any connectivity. It would be a good idea to lower the delta CRL publishing interval to 1 hour if this was being used as a “lockout” methodology, so that DC’s would know sooner that the computer was untrusted.
• The whole NAP… thingy. I don’t know much about that, but it’s there for these sorts of network trust scenarios.

I bet I got at least one more good method in the comments section. Will it be yours?

Statement

Hey, thanks for writing article <foo>. It:

A. Gave me good info.
B. Saved me time.
C. Fixed my problem.
D. Saved me from a résumé generating event.

[Obviously, I am paraphrasing pretty hard – Ned]

Response

Thanks for all the nice emails from folks that have taken time out of their insanely hectic IT days to give us an attaboy. We really appreciate them.

Plus it gives management here proof that we’re worth funding – they get to update customer satisfaction spreadsheets and whatever else managers are doing in those little offices besides playing Farm Town.

----------

As a side note, that comment I pointed to in the introduction has some info uncovered by our pal cortez, plus further clarification from me and the AD development team about using domain controllers with virtualization. I recommend you give it a read. Unless you like late nights.

Until next time.

- Ned “Hey, a post not about USMT or DFSR. Weird.” Pyle

Hiya folks. The mail sack was a no-show last week since I was out of town; I hope you can find it in your heart to forgive me. If not… well, you get what you pay for. To make up for it, this one is longer than usual. Here are some interesting issues from the past two weeks (both from the Internet and internally too).

• DFSR and temporary files
• ADUC defaults
• Inter-CA communication
• Third party software recommendations
• Compatibility mode

Question

I’m replicating files with DFSR. I’ve found a large number of files that have had the TEMPORARY attribute set on them. I know that DFSR won’t replicate those files, so I am going to remove that attribute. What happens after I do that?

Answer

Short answer: they will replicate. :-)

Long answer: DFSR treats temporary files like they do not exist. This means if a file was normal and replicated between servers, then someone sets the temporary attribute on that file, it is no longer there as far as DFSR is concerned. When a file no longer exists, we treat it as  - wait for – deleted! So the downstream servers from the originating change are going to delete that file.

Here is the debug log from the server where the temporary attribute was just set:

20100325 17:48:46.067 1836 USNC  2881 UsnConsumer::TombstoneOrDelete LDB Updating ID Record: <— Hmm, looks like it’s being treated as a deletion to me.
+    fid                            0x700000000EB52 <— Note the File ID
+    usn                             0xfa1ead8
+    uidVisible                      1
+    filtered                        0
+    journalWrapped                  0
+    slowRecoverCheck                0
+    pendingTombstone                0
+    internalUpdate                  0
+    dirtyShutdownMismatch           0
+    meetInstallUpdate               0
+    meetReanimated                  0
+    recUpdateTime                   20100325 21:47:46.739 GMT
+    present                         0
+    nameConflict                    0
+    attributes                      0x20
+    ghostedHeader                   0
+    data                            0
+    gvsn                            {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v277 <— Note the version
+    uid                             {F5C8EE4D-3C55-42A4-BB62-63F72E7EEBED}-v50
+    parent                          {780F3375-CDB0-4583-A3AE-85845086E884}-v1
+    fence                           Default (3)
+    clockDecrementedInDirtyShutdown 0
+    clock                           20100325 21:48:46.067 GMT (0x1cacc64f1e63a10)
+    createTime                      20100325 21:47:29.386 GMT
+    csId                            {780F3375-CDB0-4583-A3AE-85845086E884}
+    hash                            E30F7F47-58F6FE00-B9846C04-43B82E2A
+    similarity                      00000000-00000000-00000000-00000000
+    name                            ohnoes!.txt <— Note the name
+   
20100325 17:48:46.067 1836 USNC  2887 UsnConsumer::TombstoneOrDelete ID record tombstoned from USN_RECORD:
+    USN_RECORD:
+    RecordLength:        96
+    MajorVersion:        2
+    MinorVersion:        0
+    FileRefNumber:       0x700000000EB52 <— Same FID
+    ParentFileRefNumber: 0x1AD000000008E29
+    USN:                 0xfa1ead8
+    TimeStamp:           20100325 17:48:46.067 Eastern Standard Time
+    Reason:              Basic Info Change Close
+    SourceInfo:          0x0
+    SecurityId:          0x0
+    FileAttributes:      0x120 <— This is 0x20 && 0x100, which is a file with the archive bit and the temporary attribute set. Testify!
+    FileNameLength:      30
+    FileNameOffset:      60
+    FileName:            ohnoes!.txt <— Same name

20100325 17:48:46.114 2304 JOIN  1244 Join::SubmitUpdate Sent: uid:{F5C8EE4D-3C55-42A4-BB62-63F72E7EEBED}-v50 gvsn:{16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v277 name:ohnoes!.txt connId:{2F726EBA-3970-4AA5-AD23-4C07600CE427} csId:{780F3375-CDB0-4583-A3AE-85845086E884} csName:condelrf <— Same name, same version being sent to the server’s partner. Since the last operation was delete, guess what we’re telling the other server to do?

Then later, I remove the temporary attribute:

20100325 17:49:07.523 1836 USNC  2703 UsnConsumer::CreateNewRecord LDB Inserting ID Record: <— Well hello there! Just like a new file got added. It will replicate out momentarily…
+    fid                             0x700000000EB52
+    usn                             0xfa1eb98
+    uidVisible                      0
+    filtered                        0
+    journalWrapped                  0
+    slowRecoverCheck                0
+    pendingTombstone                0
+    internalUpdate                  0
+    dirtyShutdownMismatch           0
+    meetInstallUpdate               0
+    meetReanimated                  0
+    recUpdateTime                   16010101 00:00:00.000 GMT
+    present                         1
+    nameConflict                    0
+    attributes                      0x20
+    ghostedHeader                   0
+    data                            0
+    gvsn                            {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v278
+    uid                             {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v278
+    parent                          {780F3375-CDB0-4583-A3AE-85845086E884}-v1
+    fence                           Default (3)
+    clockDecrementedInDirtyShutdown 0
+    clock                           20100325 21:49:07.523 GMT (0x1cacc64feb0277e)
+    createTime                      20100325 21:49:07.523 GMT
+    csId                            {780F3375-CDB0-4583-A3AE-85845086E884}
+    hash                            00000000-00000000-00000000-00000000
+    similarity                      00000000-00000000-00000000-00000000
+    name                            ohnoes!.txt

Craig Landis has written all kinds of interesting stuff about the temporary file attribute and DFSR in this old blog post here and now in the new TechNet Wiki here. Maybe someone will update the Wiki with this new tidbit? Hmmm…. could be you!

Question

Is there a way to make the “AD Users and Computers” snap-in (DSA.MSC) always open in “Advanced Features View” by default? I can’t find any command-line switches or registry settings that handle this scenario.

Answer

Oh MMC, how you taunt us. ADUC stores all of its configuration info inside of a special (read: not well documented and highly proprietary) cache file in your profile. You can see it by opening this folder:

%appdata%\microsoft\mmc

Good luck reading the contents of the DSA file though. The setting is stored in there as binary goo. I suppose you could copy your cache file around from place to place and use that, but seems like it would be a rather risky operation with little gain over the the 2 seconds it takes to click:

Perhaps a better idea is to have an "Admin” Terminal Server that has all your favorite applications configured the way you like ‘em. Maybe even using RemoteApp.

Question

I am looking for documentation on how the Root CA communicates with the Sub CAs in a Microsoft PKI. Once the self-signed certificate has been put on the Root CA, is it enrolled or replicated to the Sub CAs? I guess the question is this: once the self signed certificate has been put on the Root CA is it enrolled or replicated to the Sub CAs? We have NPS installed and are using it as a Radius server for the AP's and Wireless LAN Controller. We have a 802.1x policy configured and have the NPS Server validating the wireless client. The client is getting a Wi-Fi policy and a PKI-Policy through a Domain Group Policy. In this environment the wireless clients are getting a certificate with a PKI Policy but when you look at the certificate on the laptop once the system has been logged on the certificate could be issued from any of the Sub CAs. Is this the normal process?

Answer

Root CAs and subordinate CAs don't "communicate" with each other in quite that fashion. In fact, the only time any user or computer (sub CAs included) would need to contact the Root CA, outside of management tasks, is if they wanted to request a certificate. Within the sphere of the Windows CA itself, the answer to your question is no, the root CA certificate is not automatically propagated to subordinate CAs. This task must be done via another process.

If the Windows root CA has been installed on a domain server then the CA will automatically publish its root CA into Active Directory. Every Windows workstation or server will automatically retrieve the root certificate once its presence is detected and thus trust the new CA. If the Windows root CA was installed on a non-domain server then the root certificate must be published to Active Directory manually. Since you mentioned that enrollment is occurring successfully, I don't believe that trusting the root CA is an issue for you.

The next thing to address is how Windows client select the CA from which they request a certificate. The following discussion assumes that CEP/CES has not been installed and that CAs are installed in Enterprise Mode. This process applies to any version of Windows from Windows XP onwards. First, there are two contexts in which certificates can be requested -- the user context or the local computer context. Users can request certificates manually via the Certificates MMC snap-in or the Web Enrollment pages, or certificates may be assigned by an Administrator and distributed by Autoenrollment. Computer certificates can also be requested manually by a local Administrator using the Certificates MMC snap-in, or also by Autoenrollment. Regardless of the context, or how enrollment occurs, the process is the same.

1. The Windows Certificate Client (WCC) queries Active Directory for a list of certificates for which the account (user or computer) has Enroll (or Autoenroll) permissions. This information may be cached in the registry, but is periodically refreshed.
2. The WCC then queries Active Directory for a list of available CAs in the forest. Each CA publishes an Enrollment Services object that holds the FQDN of the CA server and the list of templates available on that CA.
3. The list of templates and the list of CAs (and their configured templates) are combined to build a list of those templates for which the account has permission to request a certificate AND which are available on some trusted CA in the forest.
4. In the case of the Certificates MMC snap-in, this combined list is presented in the UI as a list from which the user can select. In the case of Autoenrollment, this list is compared against those templates assigned to the account via Group Policy.
5. Once a template and the CA have been selected, the public/private key pair is created, the request is generated, and the request is submitted to the CA. Depending on the template settings, the request may be fulfilled immediately or it may be pended so that the request can be manually approved.

What this means for you is that you need to determine the following:

1. Is the Root CA in Enterprise or Standalone mode? If the latter, it will not issue certificates based on templates which eliminates the ability to request certificates via the MMC, or through Autoenrollment.
2. Do you have a certificate template that you assign specifically through your PKI-Policy? If so, on which CAs is that template configured? Check the Certificate Templates folder in the Certificate Services snap-in. (HINT: If you don't have one, the CA is in Standalone mode.)

So, if your root CA isn't configured to issue certificates based on your PKI-Policy template, or is in Standalone mode, but your subordinate CAs *are* configured to issued certificates based on that template, then it's no surprise all the certificates you've looked at were issued from one of the subordinate CAs. Funnily, this is actually a good thing. The purpose of a root CA is to be a Trust Anchor for your entire PKI. It issues certificates to subordinate CAs, which in turn issue certificates to users and computers on your network.

If you want an old but still decent introduction to PKI concepts check out Microsoft Windows 2000 Public Key Infrastructure (http://msdn.microsoft.com/en-us/library/ms995346.aspx). If you want the latest and greatest info and a lot more depth, you should pick up the book "Windows Server 2008 PKI and Certificate Security" by Brian Komar (http://www.microsoft.com/learning/en/us/book.aspx?ID=9549&locale=en-us)

[If you can’t tell, this came from Jonathan, the man who never uses a sentence when a paragraph will do – Ned]

Question

Hey, there are a bunch of different companies that make software to do X. Can you recommend one?

Answer

Nope! If I recommend one over a bunch of others, the others can get really mad. And in case you haven’t noticed, we, ummm, get sued a lot. Even if the other ones don’t sue and only complain loudly over the Internet, and shaking that bush is a real no-no here in Support. So forgive us if we take a pretty hard line and recommend nothing.

I will say this: any good vendor will be more than happy to let you run a fully functional time-bombed trial edition and give things a whirl. An excellent one will let you access their online knowledgebase and support forums before you buy. I am always suspicious of those who do not want you to see any dirty laundry until the check has cleared. Everyone has a competitor; there are no real monopolies in the software world. Use that to your advantage when evaluating new products.

Question

On a Windows Server 2008 R2 computer I can only get back to Vista for compatibility mode (this computer is running some old stuff via remote desktop services). Why is this and is there a way to at least get back to XP mode?

Answer

You tricked yourself – it depends on the application architecture you are running:

The one on the left is a 32-bit program. The one on the right is a 64-bit program. Both are on the same computer. Win2008 R2 runs 64-bit only and when it comes to 64-bit programs, can only pretend back as far as Vista 64-bit RTM. If you need more than this you will need to pay a visit to the Application Compatibility Toolkit. Or, you know, upgrade your crummy old app… ^_^

Hey, sometimes the questions aren’t about DS necessarily. They just need to be interesting enough to make me care. In this case I had no idea, had to figure it out.

Until next time.

- Ned “get to da choppah!” Pyle

In addition to the normal list of KBs and blog posts, here is a look at the topics related to Directory Services that have been created on the TechNet Wiki recently.

TechNet Wiki Topics

KB

Blogs

KB

Blogs

KB

Blogs

Earlier this week the TechNet Wiki Beta site went live. Now instead of just providing additions to articles like you could with Community Content on MSDN and TechNet, you can create new content and edit anything to your heart’s content. Some of us think this could be rather a big deal.

Certain types of technical content may never do well on a wiki, because they need to be read-only as they are the company’s official guidance. If you are trying to use Microsoft’s best practices, for example, you may not be inclined to get that from a wiki.

But there is also content that could do well being vetted, edited, and augmented by the community. Some content stands on its own merit. You read it, you understand it, it makes sense, and it works. You don’t need to take anyone’s word for it because you can easily and safely try it out for yourself.

So sign up and give it a go. The more the merrier.

technet.com/wiki

Keith Combs gives a good overview with his blog post here -

http://blogs.technet.com/keithcombs/archive/2010/02/23/technet-2-0-episode-6-wiki.aspx

Thoughts? Drop us a comment.

KB

Blogs