Author: Andreas Stenhall

The other week I stumbled across a very interesting fact, a fact that the Windows Deployment Server service refused to start on a clean installed Windows Server 2008 R2. After troubleshooting for a whole day, even reinstalling the OS, reproducing the error even without any patches seemed very strange. The WDS service is a service that normally just works. The following error was logged:

Log Name: Application
Source: WDSServer
Date: 2010-10-04 17:14:23
Event ID: 257
Task Category: WDSServer
Level: Error
Keywords: Classic
User: N/A
Computer: wds.contoso.com
Description:
An error occurred while trying to start the Windows Deployment Services server.
Error Information: 0xFFFFFBB3

An important fact is that the server to be used for deployments was a retired yet powerful TS/RDS server with two six core processors using hyper threading, making it 24 logical processors.  Not likely to be the hardware specs of a regular deployment server but hey, it can obviously be scenarios where this might be an issue. Thanks goes to a colleague (Jeanette) who figured out that we could try to set the number of logical processors being used to two. Guess what, after a reboot the WDS service started just fine!

To change the number of used processors we used:

bcdedit /set {current} numproc 2

To revert this change you could use:

bcdedit /deletevalue {current} numproc

After some work with Microsoft Product Services and Support it appears to be a bug nevertheless. The limit for the number of logical processors you can have for the WDS service to start is 20. Bear this in mind…

Many of you surely remember the tools “vsp1clean” and “compcln” which was used after service pack 1 and service pack 2 installation to remove older Windows packages which was superseded by the service pack. These tools freed some disk space and as it removed all previous Windows components it made the service pack installation permanent, meaning it was not uninstallable after running the tools.

Anyway enough with history, when you have installed SP1 for Windows 7 or Windows Server 2008 R2 you can make it permanent by using the below command.

%windir%\system32\dism.exe /Online /Cleanup-Image /spsuperseded

You can also use Disk Cleanup to accomplish this, choose to clean your system disk and then choose “Clean up system files”, choose your system disk once again and then make sure that you select “Backup files required to uninstall service pack”.

NOTE 1: As SP1 is in beta at the time of this writing, I must warn you that running the above command will make it impossible to uninstall the SP1 beta, in practice meaning you will have to reinstall your machine once SP1 final release is made available.

In Windows you might know that a lot of services do not run as separate processes, instead many of them are actually run within the famous svchost.exe processes. To see this in action just go to a cmd.exe and type “tasklist /svc” and it will list all processes and subprocesses. It might look like:

svchost.exe    AeLookupSvc, Appinfo, AppMgmt, BITS,
               Browser, CertPropSvc, gpsvc, IKEEXT,
               iphlpsvc, LanmanServer, MMCSS, ProfSvc,
               Schedule, SENS, SessionEnv,
               ShellHWDetection, Themes, Winmgmt, wuauserv

If you need to do some troubleshooting or investigate something related to a certain process that is running with other services you can split this service to make in run in its own process. This is done by using the command:

sc.exe config servicename wuauserv type= own

Which in this case makes sure that the Windows Update service (wuauserv) will be run in its own process, for you to troubleshoot. Set it back to its original setting by changing “own” to “share” in the above command. You can find more information about this in KB934650.

Remote Server Administration Tools is great when you want to administer your servers from your Windows 7 clients. If you are using ADUC (Active Directory Users and Computers) you might have noticed that you are missing some tabs when you choose Properties for a user account? The solution is to be found here!

If you are working with or setting up solutions around Remote Desktop Services, do not miss the collection of hotfixes related to RDS at the Microsoft Support web site. The hotfixes are categorized by RDS role and area, for instance RemoteApp, authentication, RD web etc.

The Springboard tour finally arrives in Stockholm on October 27th. The event is an all day event about deploying Windows 7 and Office 2010 and is totally free to attend. More information at Springboard series website.

There is a bug in Windows Deployment Services (WDS) in Windows Server 2008 R2 which prevents your pre-staged computers from booting via PXE. In the Event logs on the WDS server you can find event 519 stating that there are duplicate machines with the same GUID or MAC address, even though this is not true. There is a hotfix for this problem which is available from http://support.microsoft.com/kb/2028840/en-us.

The event looks like:

Log Name: Application
Source: BINLSVC
Date: 2010-09-24 10:29:04
Event ID: 519
Task Category: BINLSVC
Level: Error
Keywords: Classic
User: N/A
Computer: wds1.contoso.local
Description:
Multiple machine accounts with the same GUID or MAC address were found in Active Directory Domain Services. The Windows Deployment Services server will use the first listed machine account.

List of matching machines: CN=DEPLOYTEST1,OU=CONTOSO,DC=stenis,DC=local

There is a very common misconception out there that Group Policy Preferences can only be created, managed and applied to your Windows machines if you are running your domain controllers with Windows Server 2008 or later. This is so NOT true.

What you have to do if you are stuck on domain controllers running Windows Server 2003 is to install the Remote Server Administration Tools on a Windows 7 (or Vista) client machine, add the feature Group Policy Management and then create a GPO in the domain and edit it, configuring the Group Policy Preferences of your choice. Voilà!

I do not know where this myth is coming from actually but the fact that GPO Preferences were introduced in Windows Server 2008 is the major reason I would assume.

At the TechNet/MSDN after work I attended last week I got an interesting question on why a user (domain admin) gets a UAC popup on trying to access folders via Explorer which he knows for sure he is supposed to be able to access looking at the ACLs of the folder. Instead, when clicking OK on the UAC popup the ACL is populated with his account.

My first thought to this behavior was Explorer.exe not being able to elevate and the “split personality” i.e. the two security tokens involved when UAC is in effect. Here comes a more detailed explanation that I think is of interest to more. Note that this problem also covers some other scenarios such as AppLocker rules not appearing to work as intended for administrators. Read on to learn what is causing this.

First when UAC is enabled you get two security tokens when you log in, easily explained as one which contains the administrator privilege information and one which does not. Most of the times you run everything using the standard security token. When you for instance want to install software or change some system settings, then the security token containing the administrator privileges information is used.

If you do not explicitly request an application to launch with higher privileges, or the applications itself request higher privileges, all processes and applications run in the user context with the standard security token. Virtually all applications including Windows applications and processes are possible to elevate by right clicking and choosing “Run as administrator”. This is not true for Explorer.EXE though as all your attempts to elevate it will not result in any actual elevation. There are a few caveats with this and let us continue with the example of access certain files and folders.

So let’s have a look at what the ACL of the folder D:\Share looks like:

We can clearly see that there are no user accounts in this list. Under normal circumstances any user which is a member of the domain admins group should be able to access that folder but instead is presented with the UAC dialogue:

What happens when the user “stenis” in this case clicks “Continue” to that UAC dialogue box questions is that the ACL is populated with the user account in questions:

This happens because the fact that Explorer.exe cannot be elevated the normal Windows Explorer does not see that the user account should be able to access that folder. It is easy to verify as you can actually run Explorer.EXE elevated by changing the registry setting “RunAs” to “_RunAs” in HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Thanks goes to Andre Ziegler for this finding.

So what does this tell us? It is a somewhat strange problem but still by design. The fact is that this “problem” is not applicable to the folder and file access as described in this blog but also for AppLocker rules for instance, as many domain administrators must choose “Run as administrator” to be able to run software which they think they should be able to run without this little procedure.

This afternoon I held a chat about Windows 7 hosted by the Swedish MSN website. The chat was in Swedish and I have now put the transcript up for everyone to enjoy at my Swedish Windows site.