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