When software attacks!

Thoughts and musings on anything that comes to mind

Install System Center Capacity Planner 2007 on Windows 7

I’ve been using Windows 7 for a while now, but I’ve never needed to install the System Center Capacity Planner (Andy usually handles that side of our SharePoint engagements). He now has taken the plunge with Microsoft’s shiny OS and hit a problem: SCCP refused to install with an error message saying it was only supported on Windows XP (!)

We tried all sorts, and in the end I resorted to our old friend, Orca – the MSI editor shipped with the Windows SDK. Looking through the tables I found an entry in LaunchCondition specifying ‘VersionNT >=500 AND VersionNT <=600’

One quick hack later and it was looking for less than ‘700’ and the installer worked.

image

Luckily, the SharePoint Planning installer needed no such hacking.

Windows 7 on the 8Gb SSD Mini 9: Redux

You may remember that I ended my previous post with about 1.6Gb free on the 8Gb SSD of the Mini 9 after installing Windows 7.

I still needed to install Office 2007, or at the very least Word and Excel for the ‘book to be useful. I therefore rummaged out another 16Gb SD card and revisited my earlier vista post about installing apps to an SD card. This time I simply let the card allocate a drive letter and installed Office to d:\Program Files instead.

The trouble was, after installing Office I was down to about 400Mb free on the Dell’s SSD, despite installing the suite to the SD card. There are two reasons for this: Firstly, the common stuff goes into c:\program files\common files\microsoft shared; secondly, the installer files are stored in c:\windows\installer.

I then followed the steps in my post about moving installer files with Vista and created d:\Windows\Installer to hold the data. I’m now back to 1.3Gb free on the SSD. I have successfully installed a couple of apps (including some of the Wave 3 Live suite) following the change so I am pretty confident it works.

I should point out at this juncture that after my previous post I received an email about junctions, Windows installer and Windows XP. That email warned me that performing the steps I documented with Windows XP was extremely dangerous and I should warn people against it. I did ask the mailer the reason why so I could post more detail, but I never got a response. The moral? Do this at your own risk, people.

Ultimately, I wouldn’t recommend the 8Gb SSD as a realistic option. The XP install shipped on it is compressed and slow. My Windows 7 solution is compressed (although not as slow as I had expected – it’s quite usable). Most importantly, once you’ve got the OS on, you’re a bit stuffed for anything else without resorting to hacks like the ones described here. I would say that 16Gb is a minimum, and depending on your needs a 32Gb SSD might be worth the money.

Windows 7 on the Dell Mini 9 with only the 8Gb SSD

In my previous post about getting Windows 7 onto the fantastic Dell Mini 9 I talked about solving things like the driver issues and antivirus. This time I’m going to cover how I installed Windows 7 onto the 8Gb SSD version of the Mini 9.

Interestingly, Windows 7 will actually install in about 8Gb. However, when I tried to run through my previously documented steps, it told me that it did not recommend installing to a disk of less that 8303Mb. The Dell had about 7.5Gb free for the install as I wanted to leave the Dell system partition alone. When I tried to install the process reset partway through and I could not stop it doing it.

So I had a think. My final solution, in a nutshell, is the following:

  1. Install to a VPC with a small disk but stop before the final step where it runs the OOBE (preparing to start for the first time…)
  2. Boot the VPC from another source and compress the contents of the disk.
  3. Create an image of the new disk and transfer that to the Dell.
  4. Complete the installation.

The good news is – it works!

So, let’s run through that again and put a bit more detail into it.

To do this yourself you’ll need the following:

  • The drivers and software for the Dell Mini I listed in my previous post.
  • The Windows 7 x86 install iso.
  • The Windows 7 WAIK beta (to create WinPE media)
  • Virtual PC 2007
  • It’s also easier to have Windows 7 running on the PC you’re going to use to host the VPC for reason which will become clear soon.

Step 1: Create the VPC

I guess you don’t really need to limit the VPC to the same memory and disk as the Dell, but I did. Create a new VPC using the Vista template as the base. Set the memory to 1Gb and set the hard disk size to 8192Mb. While you’re at it, use the virtual disk wizard to create another VHD of the default size (16Gb, it’s more than enough) and call it something like ImageDisk. Don’t attach it to the virtual machine just yet.

Step 2: Install Windows 7 from the ISO

Attach your Windows 7 ISO to the virtual machine and boot from it. Choose your language as normal and select the 8Gb disk to install to. Don’t disappear and leave the installer to it, however – you need to pay attention.

The installer will copy files and uncompress them. It then does a couple more steps and does a reboot. At this point, because I’m paranoid, I shut down the VPC and copied the VHD file.

Let the VPC reboot. Again, pay attention. The installer carries on for a little while and then the system will restart. Again, shut the VPC down before it boots for a second time. Once again, I copied the VHD out of paranoia.

Step 3: Compress the disk contents

There’s an irony here – the installer has just merrily uncompressed all your files and now you want to shrink them back down again. Ah, well…

Boot the VPC from the installation CD. When you get the install screen up press Shift+f10 to open a command prompt.

Change to the root of the c: drive and type the following:

c:\windows\system32\compact.exe /c /s /i

This will run through and compress all the files except hidden and system files like the page file and hibernate file. It takes a while, but it will take a heck of a lot less time on your VPC than it would if we tried this on the Dell.

Once it’s finished, type:

c:\windows\system32\shutdown /s /t 0

or power off the VPC.

Step 4: Create a Win PE disk

I’m not going to run through the process of creating a WinPE disk. Install the WAIK and follow the instructions. You should end up with an ISO file that can be used to boot the VPC. Make sure you copy imagex.exe onto it!

Step 5: Image the VPC

We now need to create a .wim image of the installation we’ve partially completed. The easiest way to do that when using a VPC won Windows 7 is to mount a second VHD file and create the image on that. We can then attach the VHD to our Windows 7 host PC and copy off the image file.

First of all, we need to partition and format the VHD we create to store the image. On your Windows 7 host computer, start Computer Management as an Administrator (type ‘com’ into the start menu, right click the computer management icon, chose ‘run as administrator’).

Right-click on the Disk Management icon beneath Storage in the left hand pane and choose ‘Attach VHD’. Browse for your VHD file and click OK to mount it. You should see the new disk appear in the right hand panel.

We can do everything we need in Computer Management, but I find diskpart to be quicker. Open an administrative command prompt and type diskpart to fire it up.

We need to create a new partition. Computer Management helpfully tells us the number of our VHD so we can type that into diskpart. For example:

select disk 1

Then to create a partition:

create partition primary

And then, being eclectic, I use Computer Management to quick format it as NTFS because it’s easier to right-click the disk and choose ‘Format’!

Now we have a formatted partition, we can right-click the disk in computer management and detach the VHD. You can do that in Diskpart as well, I know…

Now edit your VPC configuration and add the second VHD. Boot the VPC from the WinPE ISO you created and you will end up with a command prompt.

The next bit is easy:

imagex /capture <drive letter of our system disk, hopefully c:> <drive letter of our big empty disk, possibly d:>\Mini9.wim “Mini9”

The sytem will chug for a while and you will be left with a shiny wim file on the second VHD. Mine was about 2.7Gb.

Step 6: Transfer the image onto the Dell

The easiest way to do this is to create a WinPE USB stick with your wim file on it as well. You’ll need to format your USB stick as NTFS and then xcopy the WinPE disk contents onto it. Make sure you use the /S (subdirectories), /H (copy hidden and system), /E (copy empty directories) and I usually tack on the /Y (don’t prompt) for a quiet life:

xcopy <source drive>\. <usb drive>\ /s /h /e /y

Then copy your .wim file on as well.

I usually use the Windows 7 install media to delete the original OS partition from the Dell, simply because the UI is nicer than using diskpart. You may differ. If you follow the WAIK instructions and use the diskpart ‘clean’ command you risk losing the Dell partition as well.

Armed with a nice empty Dell disk, boot from your USB WinPE disk.

First we need to partition the disk:

diskpart


list partition

<you need to remember the number of the big partition! I’m going to assume it’s 1 for now>

select partition 1
active
format fs=ntfs
assign
exit

And now you should have a nice big empty partition which you need to work out what drive letter WinPE has assigned (it may or may not be c:)

To put your image onto the disk use the following:

imagex.exe /apply <usb disk path>\Mini9.wim 1 <dell disk>:\

Once again, site back and wait. When the imaging is completed you can shutdown the Dell, remove your USB stick and follow the same procedure as I talked about before to get your drivers installed.

Still to do…

I haven’t sorted out applications yet. There’s only about 1.6Gb free on the disk after this process is completed. I am looking at using the SD card for applications in the same way as I talked about in my post about Vista and junctions.

Achieving HDMI audio output with ATI hardware on Windows 7 (and Vista)

The steps in this article were figured out with Windows 7. However, they should work just fine with Vista for anybody having the same issues. Note that whilst this is written for ATI hardware, it may be the case that NVidia gear suffers from the same problem and this solution should help.

Background first. I spent a while sorting our AV gear so I could use HDMI as the universal connection standard. At the heart of this is an AV receiver with a number of HDMI inputs and HDMI output to the TV.

I spent a while looking at how to achieve audio output over HDMI for the Media PC we have. The previous model, which had given exemplary service, was built around a Shuttle SN41G2 chassis. With the graphics card it had, DVI was possible, and optical digital output, but it didn’t have the grunt to decode high definition video, so it needed replacing.

As I mentioned in a previous post, it’s replacement was a Hiper barebones built around the AMD 690G chipset which has HDMI output and, critically, will support audio over HDMI.

I started the great process of connection and configuration simply – PC plugged directly into TV. In this configuration, I simply set the HDMI audio output device  as the default output device and happily got sound from the TV and faultless video.

That was easy! I unplugged the PC from the TV, plugged it into the AV receiver and continued to get sound and video. Brilliant!

Reboot the PC, however, and the video gets crappy and the audio disappears.

I did a great deal of digging and found a whole heap of discussion related to this issue on the fantastic AV Science Forum. The problem, it turns out, is widespread, and afflicts owners of ATI hardware the world over when connecting to AV receivers of all makes and models. The root cause seems to centre around the capabilities information passed down the HDMI connection when plugged into the AV receiver. For some reason, it seems to confuse the capabilities of the TV and receiver in such a way as to convince the PC that audio is not supported.

The solution, it turns out, is to create your own device driver .inf file which details correctly the capabilities of the TV and receiver and overrides the connection information.

The forums had much discussion involving registry hacking, copying and pasting of hex data into. inf files and much more. However, they also focused on a tool referred to in the forums as moninfo. A bit of googling later and it turns out they mean Monitor Asset Manager – a free utility from EnTech, makers of the mighty PowerStrip shareware tool.

Armed with this mighty tool, the steps to success are as follows:

  1. Connect the PC to your TV (no AV receiver in the loop). I would reboot the PC to make sure it’s sensed everything correctly at the start of the process.
  2. Run Monitor Asset Manager. It will display all manner of information detailing the TV and its capabilities.
  3. Click the file menu and hit ‘Create INF…’ and give the file a sensible name (mytv.inf for example).
  4. Hit F5 to refresh the moninfo display. Make sure it refreshes correctly. You may need to click on different bits of the window to make sure focus is set correctly.
  5. Now comes the tricky part. Unplug the TV from the PC. You now need to connect the PC to the AV receiver, but making sure that the receiver is not connected to the TV. This means you won’t be able to see anything on screen so make sure you don’t accidentally switch focus away from moninfo. You can’t have any other displays attached either, as this will confuse the information moninfo sees.
  6. Working blind, hit F5 a few times to make sure the moninfo details are refreshed with the information from the receiver. Leaving the PC for a few minutes to make sure all the hardware connections have sorted themselves first is a good idea.
  7. Disconnect the PC from the receiver and reconnect to the TV so you can see what you’re doing. Don’t refresh moninfo!
  8. Repeat the process to create a new .inf file. Call it something like myreceiver.inf.
  9. The next part moninfo can do for you, but I did it myself to make sure I knew what was going on. Choosing ‘merge extension block with inf’ from the file menu should allow you to take a crucial bit of the sensed details from the AV receiver and combine them with the details in the tv inf file. I did by hand.
  10. Create copies of the mytv.inf and my.receiver.inf.
  11. Open myreceiver.inf. You will see a line which says
    ;Extension bloc #1, e.g. , CEA-EXT, DID-EXT, etc.
    Copy the line beneath it which begins HKR, EDID_OVERRIDE,”1” to the clipboard.
  12. Open mytv.inf. Find the same line
    ;Extension bloc #1, e.g. , CEA-EXT, DID-EXT, etc.
    Replace the line beneath it with the line from your clipboard.
  13. Save the .inf file as something else (mytvandreceiver.inf)

You now have a device information file which will override the information received over the HDMI connection and convince your PC to support the output formats it should do – including sound!

Connect your systems up how you actually want them – PC to receiver, receiver to TV and reboot the PC.

In Windows 7, to use the custom .inf file with your monitor, follow the steps below:

  1. Right-click the desktop and select Screen Resolution.
  2. Click the link on the right hand side of the dialog which says ‘Advanced Settings
  3. In the dialog that appears, select the Monitor tab and then click the Properties button.
  4. In the new dialog, select the Driver tab then click the Update Driver button.
  5. Select the option to ‘Browse my computer for driver software’.
  6. On the next screen, choose ‘Let me pick from a list of device drivers on my computer’.
  7. On the next screen, click ‘Have Disk’.
  8. In the file dialog, browse to the folder with your mytvandreceiver.inf file (this is much easier if it’s the only file in the folder) and select it.
  9. You should then see your device listed in the driver selection screen. Select it and click Next. You may need to confirm that you want to use the driver as it is not digitally signed.

Once you’ve got the driver installed, reboot your PC. You should find that you get the decent picture and HDMI audio that you had when plugged into the TV.

Kudos to the guys on the AVS Forums who figured all this out. It was extremely frustrating until I found their sage advice.

Windows 7: Attempting to install to VHD – an odyssey

One of the things I am most impressed about with Windows 7 is the latest Media Center. As a result, I wanted to install the build 7000 beta release onto our media PC at home. However, I already have that working nicely with Windows Vista and, frankly, I didn’t want to have to repeatedly reinstall if the beta caused problems.

The solution seemed simple: install Windows 7 to a VHD file sitting on the Vista disk. Whilst at TechEd, Mark Russinovich had mentioned that he was running Windows 7 in exactly this way, so I was pretty confident it would work.

Maybe that was my first mistake. Perhaps my second was trying Win7 x64, but when you have a 64-bit CPU why use anything less?

So, I started my quest with a 500GB hard disk which had a single partition, onto which Vista Ultimate x64 had already been installed. The disk had the thick end of 400GB free (there’s nothing installed but Vista and some codecs).

I had planned to boot from USB (the install goes much quicker that way) but whilst the BIOS of the machine saw my USB stick as a drive, the boot menu didn’t want to let me boot from it. I could have spent a while messing, but for the time it takes these days to burn a DVD, I did that instead.

So… boot from DVD into Windows 7 setup. When the first screen appears, I hit shift+F10 to get a command prompt (that’s something I didn’t know until today, and I shall be remembering it, you can bet on that!).

Once inside the command prompt I execute the following sequence of commands to create the 100GB VHD file I want to install Win7 to:

diskpart
create vdisk file=c:\win7beta.vhd maximum=100000
Diskpart successfully created the virtual disk file
select vdisk file=c:\win7beta.vhd
Diskpart successfully opened the virtual disk file
attach vdisk
Diskpart successfully attached the virtual disk file

I then exited diskpart and the command prompt, and stepped through the install as normal by selecting a language, choosing to install, not upgrade, agreeing to the licence etc.

I then got the familiar screen asking ‘Where do you want to install windows?’. This showed my a shiny new disk (listed as disk 5) which had 97.7GB of unallocated space.

Buoyed with success, I selected the disk.

‘Windows cannot be installed to this disk. The computer’s hardware may not support booting to this disk. Ensure that the disk’s controller is enabled in the computer’s BIOS menu’ said the installer.

Darn!

I didn’t have any drivers to hand that I knew were for the system I was installing to, and I couldn’t be bothered rummaging around the web for them when I didn’t know what the chipset was. So I decided to experiment a bit…

My thinking was this: Perhaps it’s because I had Vista underneath, or perhaps if I could get Windows 7 onto the machine in some other way, I might suck the drivers out of that install. I had some time, so why not experiment…

I still wanted to keep my Vista installation, so why not clear some space on the hard disk to install to a new partition? I opened a new command prompt and started diskpart:

Select disk 0
select partition 1
Partition 1 is now the selected partition
shrink desired=100000
Diskpart successfully shrunk the volume by: 98 GB

I really like that diskpart will let you shrink partitions. The fact that I can tinker with my disk layout on the fly all from within Windows 7 installation is great!

I exited the command prompt and refreshed the installation location screen. I now saw 97.7GB of unallocated space on disk 0, and chose that to install to. That ran through just exactly how you’d expect, with no issues.

At this point, however, as I watched the installation screen sitting on ‘Completing installation…’ I was thinking how doing this on a machine with no hard disk activity LED was not the best plan. Blinking lights are annoying when you’re trying to watch TV, but they’re really nice when you’re installing stuff!

Windows 7 started OK and installed a few updates. I then checked the disk controller drivers. Windows 7 was reporting ‘Standard Dual Channel PCI IDE Controller’ times two, with two each of ‘ATA Channel 0’ and ‘ATA Channel 1’.

Before attempting to find more specific drivers, I decided to try again with the VHD installation. My reasoning was that Windows 7 would now have updated the bootloader on the system, and perhaps that had some involvement in whether or not I could successfully install to the VHD.

You may be thinking that I am now drifting into the realm of folly – I have a working Windows 7 installation on the system so why continue? The answer is that I hadn’t had chance to experiment with installing to VHD before this and I wanted to get as far as I could and learn as much as I could.

Booting from the installation DVD again, I once more attached the VHD I had created on the vista drive and once more could not install. At this point, I wondered if the type of VHD had a bearing. I had failed to specify a type when I created the original VHD, meaning that it would have defaulted to being dynamic. Perhaps only VHD’s of type fixed would do the job. I therefore created a second VHD, of type fixed, called win7betafixed.vhd. Note to self – next time, choose a smaller size when testing stuff! After a good thirty minutes of staring at task manager reporting virtually no disk or CPU usage I decided that perhaps something was wrong and killed the process.

I booted Windows 7 to create the VHD through the GUI. Interestingly, Win 7 hadn’t automatically assigned a drive letter to my Vista disk in the way that Vista itself always does with multiple partitions. This time the sound of disk access and the automatic installation of a Microsoft VHD HBA device gave me more confidence. It still took a long time though…

I rebooted again and started the Win7 setup process. Once again I attached the VHD file, once again the installation routine saw the disk and once again it refused to install. At this point my frustration levels got the better of me. I will try this again on a different system, but I’m admitting defeat on the media PC.

If I have more success on other systems, or if I figure out exactly why I got nowhere with my media PC, I will let you know. My gut says that I need to find drivers for the disk controller to load during setup.

For ref, the PC is  Hyper barebones media PC  HMC-2K53A-A3) with an MSI K9AGM2, AMD 690G chipset motherboard and an AMD Athlon X2 4450e CPU.

SharePoint 2007: Following Adobe Instructions Can Cause Problems

Having just spent a long time examining the state of a new farm we’ve been working on for demonstrations, I would like to issue a warning…

The Problem: None of the ‘New…’ menu items in our document libraries would work – we were seeing the error message:

'Edit Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.

The Solution: Correcting an error in the docicon.xml file which lives in c:\program files\common files\microsoft shared\web server extensions\12\TEMPLATE\XML

The Cause: Adobe’s documentation for installation of the 64-bit iFilter. We copied and pasted the line from the documentation (yeah, I know, our mistake…) which reads:

<Mapping Key="pdf" Value="pdf.gif">

Note the lack of the trailing slash, as required by XML the world over. The line should read:

<Mapping Key="pdf" Value="pdf.gif" />

With some luck this will help others – I spent a long time searching the internet to no avail.

Managing Remote Hyper-V Servers From Windows 7

I'm using the Mini9 quite a lot lately, at least in part to fiddle with Windows 7. I decided it would be nice to be able to access our Hyper-V servers so I went looking for the management tools...

It turns out that Windows 7 ships with the Hyper-V management snap-ins. No real surprise there as my understanding is that it also includes Hyper-V (although I've not managed to run it up on an x64 machine yet so I can't verify that - it certainly isn't available in x86). To get at them, you need to install the relevant bits of Windows through the 'Turn Windows Features on or off' UI:

Windows 7 Control Panel, Programs and Feature section

Make sure the third item down is checked:

Windows Features dialog

Once that's installed, you can find the Hyper-V Management Console in Administrative Tools via Control Panel.

But it doesn't work!

John Howard wrote a very useful series of posts about solving this issue with Vista and Server 2008. It turns out that there is one bit which is still relevant in Windows 7. Setting COM Security via dcomcnfg still needs to be done:

You need to run dcomcnfg as an administrator to do this. Once in, browse through Component Services, Computers to see 'My Computer'. Right-click and pull up Properties. In the COM Security tab you need to select Edit Limits in the Access Permissions section. Make sure that ANONYMUOS LOGON has Remote Access rights enabled.

image

Once that's done, the Hyper-V management console will happily connect to remote servers.

It's quite frustrating that the management tool installation does not do this, or if security is an issue, that there isn't a more user friendly way (like an option in the snapin to help) to set the rights correctly.

Vista on Dell Mini 9: Using junctions to move files off the SSD

Flush with my success earlier in getting apps installed on the SD card now mounted as 'c:\SD Program Files' I installed a few things. I then hit a snag.

When you install apps using an MSI, the installation files get cached by Windows Installer. Steadily, c:\windows\installer gets bigger and bigger, so whilst my apps were no longer taking up space, the install files were (and some of those are quite large).

I now have an image of the Vista install so I'm becoming more cavalier. I wondered if I could move the Installer folder from c:\windows onto my SD card by copying it into the mount point, but still get Windows Installer to work as though nothing had changed.

So, first I used Robocopy with the /SEC option to copy the installer folder tree over. Next, I deleted c:\windows\installer and created a directory junction which allows the moved content to still be accessed as c:\windows\installer.

To create a directory junction, use the mklink command with the /J switch to create the installer folder in c:\windows and point it at 'c:\sd program files\installer'.

So far, it's working fine. I need to try a few more installs to be sure, though...

Vista on the Dell Mini 9: Installing applications on an SD card

I’m still trying new things with the Mini 9. I now have an image file that I can restore to the Mini which has my base install after running sysprep. The problem I have is storage space – the SSD isn’t _quite_ big enough.

So, Richard wandered in this morning and handed me a 4Gb SD card to experiment with. The question: Can we use the SD card and install app onto it?

Our initial finding was a big fat no. Visual Studio setup refused to install to ‘removable media’. Bearing in mind all we’d done at this point was stuff an SD card into the card slot I wasn’t too surprised.

I fired up computer manager and went into disk admin. The partition on the SD card was FAT32, so we replaced that with an NTFS partition for a start.

I then went into the drive properties and changed the Policy settings. By default the SD reader is set to allow instant removal. Changing that to enable write caching means I will have to use the tray icon to ‘Safely Remove Hardware’, but I think that’s the key setting to allow me to install apps. However, I wanted to make things a little more integrated, so I created a folder on the C: drive called ‘SD Program Files’ and used it as a mount point for the SD card.

Visual Studio is now happily installing to the SD card.

As a 16Gb SD card is around twenty-five quid, this makes a reasonable approach to increasing storage space, assuming apps run reasonably quickly from the drive.

That’s the next test…

Workflow and SQL Error: Part 3

As you may remember from my earlier post and subsequent follow-up, we have been seeing an issue related to workflows and the Workflow History list in SharePoint 2007. As I've already mentioned, the case is with Microsoft and I also said that I would post updates as new information arrived. Today, more detail has emerged and, as promised, I am sharing.

Whilst replicating the fault today we were having trouble - one of us had a SharePoint install that failed every time and the other had one which would not fail at all. Whilst looking at possible differences we realised that the failing site was a publishing site and the non-failing site was a team site.

After some testing, I can now report that the fault I have described only occurs when the SharePoint Publishing site feature is enabled (note, the site feature, not the SharePoint Publishing Infrastructure site collection feature). If you're not using a publishing site you have nothing to worry about from the problem we see.