February, 2010

Ned here again. As odd as it sounds, when you call Microsoft for USMT 4.0 support, you will be sent to the Directory Services team. This is because we support user profiles loading and unloading, as that is a core piece of interactive logons. It’s a tangled web.

Believe it or not, I support more than just DFSR. Really!

DS engineers at Microsoft also have to know about other dependencies USMT can take, such as the Windows Preinstallation Environment (WinPE). You can run USMT 4.0 within a WinPE session so that your scanning process takes place with the source OS completely offline. It’s a pretty slick new feature and we have some straightforward steps in the “Offline Migration with USMT 4.0” guide.

As with any new feature, some common questions start cropping up. Because Windows 7 is being deployed at insanely high rates USMT is becoming a hot topic. Below are some errors people frequently see with USMT running offline migrations in WinPE.

Error: “The subsystem needed to support the image type is not present”

This error is caused by running a 32-bit version of USMT within a 64-bit WinPE image. There are two rather obvious solutions to this:

1. Use an x86 version of WinPE when running an x86 version of USMT.

2. Use an x64 version of WinPE when running an X64 version of USMT.

It’s fine to use x64 WinPE and USMT to run a scanstate on an x86 offline OS. Always remember to specify the environment variable for the offline OS architecture being scanned. This variable is:

MIG_OFFLINE_PLATFORM_ARCH=<32 or 64>

For example, if the offline OS being scanned was 32-bit Windows XP, you would specify the following in the WinPE command prompt that is about to run scanstate:

SET MIG_OFFLINE_PLATFORM_ARCH=32

Return Code 29: “A minimum of 250 MB of free space is required for temporary files”

You see this error even if you have forty bajillion GB free. When you examine your scanstate log you will see something to the order of:

2009-12-01 15:04:25, Info  [0x000000] USMT Started at 2009/12/01:15:04:25.187
2009-12-01 15:04:25, Info  [0x000000] Command line: scanstate z:\store /offline:c:\usmt\offline.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:5 /encrypt /key:****
2009-12-01 15:04:25, Status  [0x000000] Activity: 'MIGACTIVITY_COMMAND_LINE_PROCESSING'
2009-12-01 15:04:25, Status  [0x000000] Activity: 'MIGACTIVITY_AUTO_GENERATE_OFFLINE_VERSION'
Info  [0x000000] Drive X:\ has 30 MB free; a minimum of 250 MB is required[gle=0x000000cb]
Info  [0x000000] Failed.[gle=0x000000cb]
Info  [0x000000]   A minimum of 250 MB of free space is required for temporary files[gle=0x000000cb]
Info  [0x000000] USMT Completed at 2009/12/01:15:04:26.078[gle=0x000000cb]
Info  [0x000000] Entering MigShutdown method
Info  [0x000000] Leaving MigShutdown method

This error will appear even if you are running scanstate.exe on the source computer’s local hard drive. The problem is that you’re missing a required environment variable that must be set in the WinPE CMD prompt in order to execute an offline migration. Use the following environment variable:

USMT_WORKING_DIR=<some non-WinPE path>

For example, to specify the physical computer's C:\temp path to act as the temporary storage space, run:

SET USMT_WORKING_DIR=C:\temp

Naturally, you would also see this error if not using an Offline migration and the source computer hard drive really was out of disk space, or was exceeding disk quotas.

Return Code 36: “Use /offline to run gather on this platform”

This error is especially weird because the /offline switch is only available within scanstate.exe, not loadstate.exe. If you try to follow the error’s suggestion to use /offline in the loadstate, you get a new error:

An error occurred processing the command line.
loadstate ##ERROR## --> /offline
Undefined or incomplete command line option 

The real problem is you’re running loadstate within the WinPE session, which is not possible. Loadstate must always be run within a running target OS, never in WinPE.

Scanstate /UI /UE rules with user names are ignored

Consider the following command being run in an offline migration:

Scanstate.exe c:\store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:contoso\nedpyle /ue:*\* /i:migApp.xml /i:MigDocs.xml /v:5

You would expect that /ui:contoso\nedpyle and /ue:*\* would cause the Contoso domain user NedPyle to migrate, and all other user profiles to not migrate. When run, no user profiles are migrated at all. The same exact migration run on the same computer in an online migration works perfectly and only NedPyle is migrated.

This behavior is both expected and unavoidable. The WinPE computer has no knowledge of the domain and no way to perform SID translation. Specifying /ui:domain\username or /ui:*\username is therefore an invalid command. If only the scanstate tool would tell you this!

To work around the limitation, you must use a SID in your /ui or /ue arguments. All profiles are defined in the registry as SIDs, and without the need to translate a user name USMT will work fine. So this would give the desired result:

1. The SID of my contoso\nedpyle user is S-1-5-21-1405795100-2172710363-725018148-1112.

2. My command-line to include this user but exclude all other users in an offline migration would be:

Scanstate.exe :\store /offline:offline.xml /hardlink /nocompress /efs:hardlink /ui:S-1-5-21-1405795100-2172710363-725018148-1112 /ue:*\* /i:migApp.xml /i:MigDocs.xml /v:5

To figure out SIDs I recommend the old reliable psgetsid.exe tool.

Wrap up

Want to know what all these cryptic error codes mean? Make sure you book mark the USMT 4.0 return codes matrix.

Hopefully the info above saves you a headache someday in your quest to deploy Windows 7, the greatest OS we have ever made. :-)

- Ned “two trick pony” Pyle

Nearly forgot: depending on who you ask, Active Directory turned 10 years old yesterday. Or nearly 11. Or somewhere in between.

Thanks for the reminder Rick.

OVERLYEXCITEDDORKFISTPUMPPICTUREGO!!!

- Ned "we make weird clipart" Pyle

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

KB

Blogs

KB

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

KB

No new DS-related KBs this week.

Blogs

Hi all, Ned here again. Just like last Friday, today I’m sharing some emails we’ve gotten recently. Enjoy.

• Custom schema OID
• DNS RPC integrity

Question:

I am creating a custom schema extension for AD LDS (aka ADAM). Do I need to obtain and register my OID with Microsoft?

Answer:

It's not as critical as an AD forest but still highly recommended - once you get a root OID it can be used for your entire company. You absolutely must register with MS if you intend on creating a product that will be given to third parties to extend their AD LDS schemas. If you don't get an ISO-provided root OID, don't register with MS, then provide that schema to your customers then you could damage your customers. Without registration you are ineligible for the Certified for Windows logo, which is a deal breaker for certain classes of applications within many companies.

If your AD LDS schema is never going anywhere and there’s no risk of it synchronizing with an AD schema, we have a script for generating a safe internal OID here. I really recommend that you get a registered OID though, as once you duplicate an OID in an environment, fixing the issue ranges from extremely difficult to impossible.

Question:

I can manage 2008 R2 DNS fine from RSAT on Windows 7, but accessing from DNS Management mmc on Server 2003 R2 returns “access is denied”. If I install the 2003 R2 Admin Pack on an XP Pro PC it the symptom is the same, Access Denied.

Answer:

This is expected behavior, starting with Windows Server 2008 a few years ago. RPC Integrity required by W2K8 R2 DNS Servers is not supported by the Win2000 and Win2003 versions of DNSMGMT.MSC (or DNSCMD.EXE). For the most secure experience, W2K8 R2 DNS servers should be administered from operating systems that can execute the Windows Server 2008 or later versions of DNSMGMT.MSC. So Vista RSAT, Win 7 RSAT, Win 2008, Win 2008 R2 – all running DNSMGMT.MSC.

If you wanted to de-secure your Win2008/R2 DNS servers though – obviously this is highly discouraged – you can run the following command on your Win2008 R2 DNS servers to allow down-level connectivity:

dnscmd.exe /Config /RpcAuthLevel 0

If you do this you are exposing your Win2008/Win2008 R2 DNS servers to same kind of named-pipe sniffing ‘man in the middle’ attacks that Win2003/2000 DNS administration are vulnerable to. Ideally for security, all of your DNS servers would be instead upgraded to Win2008 R2. More info here.

Question:

Why is your manager such a hugely inappropriate bull in a china shop that never knows when not to say exactly what he is thinking?

Answer:

He’s from St John’s, Newfoundland.

Have a great weekend folks!

- Ned “now to work on my midyear review” Pyle