Although I’d previously deployed Vista and Windows 7 using MDT 2010, I’d never seen this problem. The issue occurred with a captured HP ProBook x86 Windows 7 Professional build.

I had to edit the unattend.xml for the task sequence in question, and delete the Display section from oobeSystem –> x86_Microsoft-Windows-Shell-Setup_neutral. Once this was done, the strange default of 1024 x 768 (where did that come from?) was no longer applied, and Windows Setup detected and set the maximum resolution.

Doing so comes up with an error:

Performing operation "generate" on Target "Catalog".
The operation failed to complete.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentNullException: String reference not set to an instance of a String.
Parameter name: source
   at System.Globalization.CompareInfo.IsPrefix(String source, String prefix, CompareOptions options)
   at ?A0xfe36268f.ConvertToNtPath(String path)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.CbsSessionAdaptor..ctor(String bootDrive, String imageWinDir, String servicingPath)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl.InitializePackages()
   at Microsoft.ComponentStudio.ComponentPlatformInterface.OfflineImageImpl..ctor(OfflineImageInfo imageInfo)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.ComponentStudio.ComponentPlatformInterface.Cpi.PlatformImplementation.CreateOfflineImageInstance(OfflineImageInfo imageInfo)

The captured image I was trying to work with was of a 32-bit machine, and the WAIK tools I have installed on my desktop are the 64-bit ones.

The solution, as I learned here after a bit of searching, is to re-run the catalog operation on an x86 machine.

As you can’t install the 32-bit tools on a 64-bit machine, I installed the 32-bit tools on my laptop, fired up WSIM, opened the WIM image, re-ran the catalog operation, and it succeeded without errors.

You’d think that they could catch the exception and give you a useful message about running the catalog again on a compatible machine, but no…

$printers = Get-WmiObject Win32_Printer

if ($printers.Count -eq 0) {
    Write-Host -ForegroundColor red "No Printers Found"
    exit
}

foreach ($printer in $printers) {

    if ($printer.Local -and $printer.Shared)
    {
        Write-Host -ForegroundColor Green "Cancelling all jobs on: $($printer.Name)"
        $printer.CancelAllJobs()

    }
}

It will only clear print jobs on local printers that are shared out. There’s some more info about the Win32_Printer class and the CancelAllJobs method on MSDN.

Note that I haven’t included any error-checking in this script at all, so run it manually first to see if it will work. As always, run at your own risk.

To schedule it, simply create a new scheduled task:

1. Run with highest privileges
2. Run whether user is logged on or not
3. Do not store password
4. Action: Start a program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
5. Arguments: -File “C:\path-to-script-file\name-of-script-file.ps1″

It’s possible to upgrade, for example, a Server 2008 R2 Standard server to Enterprise without rebuilding Windows. This is all covered in detail on the MS TechNet blogs.

The command to do so is:

DISM /online /Set-Edition:<edition ID> /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

To view what “editions” are available to upgrade to, do this:

DISM /online /Get-TargetEditions

I had issues using a valid VLSC key in this process. A comment by Brendan P of Microsoft explains why this is the case:

MAK keys map to multiple editions, so the underlying infrastructure doesn’t accept them. If you use the generic KMS client key, as Matthew suggests, that will allow you to proceed with the upgrade, and then you can either replace the key with a valid MAK post-upgrade or just use the KMS client key to activate against your internal KMS server.

The full list of KMS client keys can be found here on TechNet: technet.microsoft.com/…/ff793406.aspx

The command I ended up running to upgrade Server 2008 /w SP1 Standard (VL) to Enterprise was:

DISM /online /Set-Edition:ServerEnterprise /ProductKey:489J6-VHDMP-X63PK-3K798-CPX3Y

The successful run looks like this:

Deployment Image Servicing and Management toolVersion: 6.1.7600.16385
Image Version: 6.1.7600.16385
Starting to update components...Starting to install product key...Finished installing product key.
Removing package Microsoft-Windows-ServerStandardEdition~blah
[==========================100.0%==========================]
Finished updating components.
Starting to apply edition-specific settings...Restart Windows to complete this operation.Do you want to restart the computer now (Y/N)?

We had 12x 250GB, and 12x 750GB drives.

There is plenty of discussion around on the web about upgrading the drives yourself, and it’s hard to get a clear picture on whether or not 2TB drives are supported. On his blog, Stephen Wagner mentions that he had used a 2TB drive successfully. This was enough for us to know, so we went out and ordered 12x 2TB Seagate Constellation ES, and 12x 1TB of the same model. We chose to use these drives because that’s what our original HP-branded ones were.

There’s also another interesting blog article about upgrading the drives here which goes into some more detail.

Ours are now all up and running perfectly without any issues, we’re still running enterprise-class drives, and we saved a heap of money.

I found several tools that were capable of doing this, but I wasn’t going to pay USD$500+ for a tool I was going to use once. In addition to that, some tools didn’t work against Exchange 2010. That equates to a pretty bad investment for our company as we’re currently migrating from Exchange 2003 to Exchange 2010.

I also toyed with the following ideas:

1. Doing it in Powershell: I’m no Powershell guru, so it would take some time – plus I’d need to move the user’s mailbox to Exchange 2010 before I could use Powershell
2. Using EWS and write a desktop app in C# (Interesting, but too time consuming)

The Microsoft Exchange Server Public Folder DAV-based Administration Tool (PFDAVAdmin) can be used to do exactly this (and a myriad of other things). Note that the tool has also been renamed and updated to work with Exchange 2010 (including EX2010 SP1).

I’ll be working with the legacy WebDAV version in this example, as the mailbox in question still resides on the Exchange 2003 server.

Andrew Shugg raised a good point in the comments section:

Worth noting that the “classic” PFDAVadmin requires .NET Framework 1.1, and if you try to install that on a modern server system (e.g. Windows Server 2008, Windows SBS 2008) you’ll get warnings about it breaking things in IIS.

If possible, install PFDAVadmin and the .NET Framework 1.1 on a desktop system or non-critical server.

1. Downloadand extract PFDAVAdmin
2. Run the tool, PFDAVAdmin.exe
3. Go to File, Connect, specify the connection details, and connect
   
4. Drill down to the mailbox in question, and then to Top of Information Store
5. Locate the starting-level folder that you’re going to assign permissions to. Ensure that the permissions are correct at that level (right-click, Folder Permissions)
6. Right-click on that same folder again, and select Propagate ACEs
7. Select the ACEs (Access Control Entries) that you wish to propagate
   
8. Leave the other settings on their defaults, so we’re Adding/Replacing the specific ACE on subfolders
9. The tool will then run through all of the folders. In my case, this user had hundreds of folders that needed to be modified:
   

The same process can be used to remove the permissions later on.

Quite handy.

dfsutil /pktinfo

To quote the inbuilt usage information:

Dfsutil /PktInfo is a special problem diagnosis command that should only be executed on the client.

The PKT Cache keeps information about referrals for previously accessed DFS paths. It also notes DFS targets that are active for each of those paths. By observing the contents of this cache, an expert user may deduct the servers serving DFS paths that are accessed.

Here’s a snippet of the output when run from my PC at work. We have a common DFS share that’s replicated Australia-wide:

Entry: \company\commondataShortEntry: \company\commondata
Expires in 143 seconds
UseCount: 2 Type:0x81 ( REFERRAL_SVC DFS )  
0:[\sydney01\CommonData] AccessStatus: 0 ( ACTIVE TARGETSET )  
1:[\sydney02\CommonData]  
2:[\perth01\CommonData] ( TARGETSET )  
3:[\brisbane01\CommonData]  
4:[\melbourne01\CommonData]  
5:[\adelaide01\CommonData]

This is as per HP’s recommendation here:
Using HP ProLiant Network Teaming Software with Microsoft® Windows® Server 2008 Hyper-V or with Microsoft® Windows® Server 2008 R2 Hyper-V

The reason for this, according to HP:

If you install the teaming software before installing HyperV, the network adapters may stop passing traffic.

If you’ve already installed both, but in the wrong order, you’ll need to uninstall both the Hyper-V role as well as the NCU.

To uninstall the NCU (I always forget how to do this, and have to look it up), do the following:

1. Start, Run, ncpa.cpl
2. Go into the properties of one of the NICs
   
3. Select “HP Network Configuration Utility”, and click Uninstall