VMware ESX3 server running within VMware Workstation 6

Paul Davey from xtravirt wrote a Guide to installing VMware ESX3 on workstation 6.

“This paper illustrates how to install and configure VMware ESX3 Server to run within VMware Workstation 6. From this, VirtualCenter, VMotion, HA and DRS features can be configured.

Although performance is significantly reduced from that of a physical server, this type of environment opens considerable possibilities for portable client demonstrations and is excellent for self training and small lab environments.

This paper assumes the reader has good technical knowledge of VMWare Virtual Infrastructure 3. The paper assumes that you know how to install the VirtualCenter2, License Server and Virtual Infrastructure Client.

The hardware used in this whitepaper was an IBM Thinkpad T60P laptop, Core Duo, 3GB memory, 120GB SATA Hard Disk.

Note: Intel CPU(s) on the hardware running Workstation 6 must have the VT technology or the performance of ESX will be very poor.  It is believed that the same applies with AMD chips with AMD-V compatible CPU’s being recommended, although it is currently untested by us on this platform.”

Read More

Performance impact of Office 2007 on Citrix servers

The Office suite plays a major part in Citrix farms. Not only is it probably the most distributed application suite around, it is also the most used and one of the most resource intensive set of applications on Citrix farms. Maintaining a stable and well performing Citrix farm is probably the greatest concern for every Citrix administrator, so the introduction of a new version of the Office suite will make those eye browses frown of the common Citrix administrator.

Microsoft introduced late 2006 a new Office suite, called Office 2007. Earlier releases of the Office suite always had a significant negative impact on the maximum number of users that were allowed to get access to a Citrix server. So the obvious question to ask is: What is the impact of Office 2007 on a Citrix server compared to Office 2003?. Are we again facing a considerable performance penalty and, if so, how large is this penalty and which specific resources are impacted?

The test

To answer this question we set up a test server (a Dell 1850, 2 (hyperthreated) Intel Xeon 3.2 Ghz with 4 GB of memory) and used the Citrix Server Test Kit to run a number of simple scripts against Office 2003 Standard Edition SP1 and Office 2007 Enterprise Edition.

To be more specific we started 30 user sessions (one session per 2 minutes) and each session did the following:
1. Log on to a Citrix server
2. Start Outlook
3. Start Word
4. Start Excel and perform a number of simple calculations
5. Start Powerpoint, insert a number of slides, type some sentences
6. Wait for 5 minutes and start from step 2 again

We acknowledge the fact that those actions cannot be compared to actual user behavior. However, it does give a quite a good picture of what the performance impact will be.

After some time we logged of 5 sessions, because those 30 sessions already used all the CPU available when using Office 2007. Then we let it run for some time more.

The Result

Now  without further let’s bring in those Resource Manager graphs. The 4 most important ones are right here:

On average some 40 %.

The same graph, but now for Office 2007:

We see an average of 70 %.

Let’s take a look on the processor queue length for Office 2003:

It almost drops down to zero.

The same graph for Office 2007:

Still quite significant!

So what we see from this small test is that Office 2007 consumes way more CPU. If we do a small math:

40% (average 2003 CPU) “ 10% (normal OS CPU) = 30%
70% (average 2007 CPU) “ 10% (normal OS CPU) = 60%

That would make twice as much CPU for Office 2007!

We also checked memory and context switches. Memory consumption was very much the same between the two versions, but context switches was a different story:

Office 2003:

On average 35.000.

Office 2007:

On average 20.000 and more stable. So this shows an opposite result compared to the CPU charts. This time the results are in favor of Office 2007.

The conclusion

Overall this table summarizes the results:

Resource Impact of 2007 compared to 2003
CPU + 100 %
Memory Same
Context switches – 40 %

So what does this mean? It means that for those environments where CPU is the bottleneck the implementation of Office 2007 will definitely mean that you will have fewer users on your existing Citrix servers. How many less? That depends on things like:
• What is the real user behavior? Remember the scripts only perform very basic user actions. Real user behavior may well be different. According to Microsoft Excel 2007 makes more efficient use of the resources available for heavy calculations and those calculations may be finished quicker. So if your users use Excel a lot, the results may differ.
• How many other applications do you make available on your Citrix server? The relative impact of the implementation of 2007 will be less if your users mainly work with other applications.

Here is graph of company that has approximately 80 applications on a Citrix server:

For this customer the CPU consumption of the Office applications combined is more than half of the total CPU demand. Introducing Office 2007 on such a server will decrease the maximum number with a third.

So what if memory is your bottleneck? Will everything be all right then? Only if memory is still your bottleneck after the implementation of Office 2007 and not your CPU. You can easily recognize when CPU is likely to be a bottleneck. Just check your % Processor Time and Processor Queue Length and if it is similar to the graphs below you’re reaching the max of your CPU:

So Office 2007 has a significant impact on the CPU. Will that make SBC as a solution less attractive? Not at all, basically it is IT as we know it. Because together with the higher resource demands we also have higher resources available. 2 years ago a 2 CPU server was the standard, nowadays a 2 duo-core CPU is the standard. What it does mean is that companies should budget for server upgrades just like they do for workstations. Furthermore we have to switch to x64 bit operating systems eventually.

By the way, Office 2007 is at this moment not supported by Citrix!. This link shows the current issues they are having and they intend to have those fixed by mid 2007!

So the information given above combined with your own Resource Manager statistics will make it possible for you to do a decent guess on what to expect when you implement Office 2007. Once you have decided on implementing Office 2007, you probably want to know how to implement 2007. Office 2007 deployment has been revised and there are conversion issues to solve. I will blog on these matters within a few weeks, so keep an eye on this website!

Read More

How to integrate App-V with SCCM without losing the features you care about

One of the most anticipated features of SCCM 2007 R2 is “App-V Integration”. We have recently tested the end-to-end scenario for this integration and we can say with confidence: it BLOWS :-( . In a nutshell, by integrating App-V with SCCM you lose App-V’s best features and reduce the solution to something that’s even worse than SCCM by itself!

So what happens when you enable the App-V/SCCM integration feature in the SCCM Management Console?

  • Control of the App-V client is seized by the SCCM client. If you had App-V running on its own before you enabled the integration, you’ll notice that all App-V apps that are published through App-V’s Publishing Server are now rendered invalid. On launch you’ll get a “Unable to initialize package information (0×00000000)” error.
  • You must now publish your App-V apps through SCCM as “Virtual Application Packages”. This works by importing the .XML file of the App-V package. SCCM will distribute the packages to its Distribution Points and you can enable those Distribution Points for HTTP(S) streaming.
  • To get the App-V apps to your clients, you’ll have to create SCCM advertisements. Basically SCCM advertisements replace the App-V Publishing Server. The behavior of getting App-V apps to your desktop now becomes eerily similar to SCCM’s way of installing applications. No more getting your shortcuts immediately upon logon (like you get with App-V); you will have to go get a cup of coffee and hope that SCCM is willing to give you your apps today.
  • If you created non-mandatory assignments, then you’ll have to go to Add/Remove Programs yourself and click “Run” for all the apps that you want. However clicking “Run” doesn’t actually run your app, it only registers the App-V app with the local App-V client. Don’t expect to see any progress bar or visual feedback that the registration actually happened; just keep scouring around in your Start Menu in hope of finding the shortcuts for your new app.
  • If you created mandatory assignments, you’ll get one or more notifications from SCCM (after some time ofcourse) that SCCM has App-V apps for you that it would like to register with the local App-V client. It will do that on *every* desktop you logon to. Prepare to spend quite a bit of quality time with the SCCM Client…
  • If you’re using either Windows Terminal Services or Fast User Switching in Vista, you’re SOL because the SCCM Client is allergic to terminal sessions. You’ll get a message telling you that “No programs are available to run from a Terminal Services session”. How nice. If you happen to be running the console session, you won’t notice this limitation because at the console session, everything works just fine. So make sure you also test your solution via a terminal session so you won’t get caught by surprise.


As a result of the findings described above, we were pretty disappointed with the solution and decided to reverse our decision to integrate App-V with SCCM. However we did like the idea of using SCCM Distribution Points to stream App-V apps from. So we had a go at doing a manual integration of App-V with SCCM so that we could use just the SCCM parts we wanted. The idea was inspired by Tim Mangan’s article which included this diagram:

In his article he never got around to actually testing if it was possible to stream an application that was published by App-V’s Publishing Server from an SCCM Distribution Point. He only verified that is was possible to install the App-V app through an MSI with SCCM. So we ventured to get HTTP streaming working against SCCM Distribution Points, with the shortcuts still being provided by an App-V Publishing Server. In a nutshell: it works! You do have to setup a few mechanisms to get load balancing working though.

Here is how it works:

  • First and foremost: disable the App-V integration with SCCM. To do this, go to the SCCM Console -> Site Database -> Site Management -> <Site> -> Site Settings -> Client Agents -> Advertised Programs Client Agent -> Properties and make sure “Allow virtual application package advertisement” is NOT selected.
  • Enable your SCCM Distribution Points for BITS, HTTP and HTTPS content transfer. To do this, go to the SCCM Console ->Site Database -> Site Management -> <Site> -> Site Settings -> Site Systems -> <your DP> -> ConfigMgr distribution point-> Properties and select “Allow clients to transfer content from this distribution point using BITS, HTTP and HTTPS”.
  • We found that (at least in the RTM version of SCCM 2007 R2) you don’t have to enable “virtual application streaming” on the “Virtual Applications” tab of the distribution point to be able to stream from a SCCM DP when using our manual integration. The added benefit of this is that you can now also use Secondary Site DP’s as streaming servers!
  • Set up an App-V Management Server on any server you like. You can even set it up on a SCCM server, it doesn’t matter. Use the default installation settings for the entire installation. After installation, set the Default Content Path to the following: http://%SFT_SOFTGRIDSERVER%
  • Add an App-V package to SCCM for distribution and streaming:
    • Go to the SCCM Console -> Site Database -> Computer Management -> Software Distribution -> Packages -> New ->Package. Enter the information about your package and click Next. Select “This package contains source files” and set the Source Directory to the location of your App-V package and click Finish. Note that you import the App-V package as a normal SCCM package and NOT as a Virtual Application Package. Importing it as a Virtual Application Package will cause the .SFT file in the App-V package to be renamed and cause the .SFT file to be added to not 1 but 2 locations on each SCCM Distribution Point, doubling storage requirements.
    • When the package is added to SCCM, find the Package ID and use it to update the streaming location in the App-V OSD files. For each OSD file in your App-V package, update the HREF statement to HTTP://%SFT_SOFTGRIDSERVER%/SMS_DP$/SMSPKG/<your SCCM Package ID>/<name of your SFT file>
      (If you are using a File Share Distribution Point, the IIS vdir may be different than SMS_DP$. Verify the vdir name in IIS Manager and ensure that all DP’s are either standard DP’s or File Share DP’s.)
    • Now add some SCCM Distribution Points to your package so that SCCM can distribute the App-V content
  • Import the same App-V package into the App-V Management Server so that you can distribute the shortcuts and set permissions:
    • On the App-V Management Server, go to the App-V Management Console, go to Applications
      -> Import Application and go to the same App-V package folder. Select the .SPRJ file and click Open. Perform your regular App-V import steps and finish the import.
    • The imported applications in the App-V Management Console should now show the correct http:// paths to both the OSD file(s) and the SFT file(s).
  • That’s it! Now just configure your App-V Clients on the desktops to use your newly setup App-V Management Server by configuring a Publishing Server and use Group Policy to set the %SFT_SOFTGRIDSERVER% to the name of a SCCM Distribution Point nearby. We set this variable to DNS name that uses DNS Round Robin to distribute the load to multiple DP’s.
Read More

Native VHD in Windows 7

I received this article from a college: Roel Janssens and I published it here with his permission.

The Virtual Hard Disk file format is getting more and more important for Microsoft (for example think Windows Azure) and with the introduction of Windows 7 Microsoft offers for the first time native VHD support. Working in Windows XP, Windows Vista and Windows Server 2003 you could mount a VHD with vhdmount, but the possibilities now have expanded and a lot more is going to happen in the future.

During TechEd 2008 Mark Russinovich gave a very interesting presentation called “Inside Windows 2008 R2 Virtualization Improvements and Native VHD Support”. The first hour has some nice enhancements in Hyper-V 2.0 and the last quarter Mark live demonstrates what Windows 7 is currently capable of regarding VHD.

All steps and findings in the following story are tested and confirmed working under Windows 7 Ultimate build 7000 and Windows Server 2008 R2 build 7000.


There is no need to install additional programs when you want to create, attach or detach a VHD, this is all default built in within Disk Management. When you are working on Windows Server 2008 R2 this is an easy way to transfer data between the parent and child partition, you can see it as a “VHD Stick”. A requirement for a child partition is that a SCSI Controller is available, otherwise you can’t live (hot) attach a VHD.

Besides working in Disk Management you now have the option to install Windows 7 inside a VHD and boot from it. After that it is also possible to make differencing VHD’s based on that installation and boot from them. Some advantages and possibilities that this offers are:

– The installation of a new Operating System no longer requires you to redesign how your partitions are arranged. All that is added is one big VHD file and one boot entry. If you want to get rid of the installation those are all you have to delete.

– Differencing VHD’s make it possible to easily and safely test an upgrade to for example a new build of Windows 7. Do you like the upgrade then you can merge the differencing VHD, otherwise throw away the differencing VHD and continue to work where you left of in the original installation.


Microsoft originally set the target of maximum 10% performance loss when Windows 7 is installed inside a VHD compared to a bare metal installation. They have done good work on this part because tests show that this loss is about 1 or 2 %. There is always some noise inside those tests so you can say that it nearly approaches a bare metal installation. My own experiences during the last weeks are the same; you almost never feel you are working inside a VHD.

The boot loader of Windows Vista isn’t compatible with VHD entries; if you look at those entries from within Vista you will see some ‘unknown’ parameters. If you also have Vista on your system and for some reason it starts up in Vista Repair then all boot entries referencing a VHD will be lost! Therefore it is wise to regularly make a backup of you Boot Configuration Database with bcdedit /export, that way you can always go back.

An option that has disappeared when booted from a VHD is the option to hibernate your machine. With power management you now only have the options of Sleep and Shut Down (this also happens when you enable the Hyper-V role on Windows Server 2008). Time will tell if Microsoft is going to develop or support hibernation when working with VHD’s.

Installation Windows 7 inside a VHD

To install Windows 7 inside a VHD you need at least 20GB free disk space. For now the installation is only supported on internal disks, so no external USB drives yet. In the following procedure we are going to install Windows 7 inside a 20GB VHD which we create in the directory c:\vhd. If you have an existing fixed size VHD (for example one created with Hyper-V Manager) you can use that one and skip step 05.

01 boot from Windows 7 DVD or USB
02 Shift-F10 for a command prompt
03 dir C: (of D: E: etc.) to see where your VHD-directory has gone
04 diskpart
05 create vdisk file=c:\vhd\win7.vhd type=fixed maximum=20000
06 select vdisk file=c:\vhd\win7.vhd
07 attach vdisk
08 exit
09 setup
10 install Windows 7 on the new 20GB Unallocated Space (ignore the warning)

After the installation there will be a new boot entry created where the system default will boot from. Start a command prompt with Administrator credentials and type bcdedit /v to see the newly created entry:

As you can see the two entries ‘device’ and ‘osdevice’ don’t reference a partition (e.g. with Windows Vista), but a physical file somewhere on your computer. The funny thing is when you are booted inside this installation you can look for this file with Windows Explorer; this is somewhat strange to understand when looking at it. Something else that changes is the location of the pagefile; it can’t exist within a VHD so Windows will automatically select another location for it.

Create differencing VHD

A differencing VHD is a disk that only saves the differences compared to his parent. This way you can quickly and easily test something without modifying your current installation. Currently Microsoft only supports placing both the parent and the differencing disk on the same volume, but this might change in the future. Parent disks are only used for read only operations while differencing disks perform more write operations, I can imagine placing them on separate disk subsystems optimized for read or write operations.

You can only create a differencing VHD when the parent you want to create a differencing disk from is not in use at that moment (so you can’t be booted inside your parent VHD). Following procedure again makes use of the boot functionality of the Windows 7 DVD, but you can also use a separate Windows Server 2008 installation and use Hyper-V Manager from there to create a differencing VHD. You don’t have to specify a size; this is specified by the parent.

01 boot from Windows 7 DVD or USB
02 Shift-F10 for a command prompt
03 dir C: (or D: E: etc.) to see where your VHD-directory has gone
04 diskpart
05 create vdisk file=c:\vhd\win7-diff.vhd parent=c:\vhd\win7.vhd
06 exit

99 No need to reboot right now, you can continue the next procedure at step 03

Now a differencing VHD is created with the previous Windows 7 installation as parent. The initial size of the differencing VHD will be very small, but this will grow during usage. When booted from within this differencing VHD and looking at it from within Windows Explorer you will see it’s size is the same as that from the parent. When you look at the VHD from another Operating System you will the normal size again.

Create additional boot entry

To be able to boot from previous differencing VHD you have to add an additional boot entry. You can do this from within a working Window 7 installation or again after booting from the Windows 7 DVD. The following steps can be done immediately after creating the differencing VHD.

01 boot from Windows 7 DVD or USB
02 Shift-F10 for a command prompt
03 bcdedit /v
04 bcdedit /copy {identifier-of-Windows7} /d “Windows 7 diff”
05 bcdedit /v
06 bcdedit /set {identifier-of-Windows7-diff} device vhd=[locate]\VHD\Win7-diff.vhd
07 bcdedit /set {identifier-of-Windows7-diff} osdevice vhd=[locate]\VHD\Win7-diff.vhd
08 bcdedit /v

In step 03 you have to look for the entry of Windows 7, you can Copy and Paste this identifier and use it in step 04. In step 04 the entry “Windows 7” will be copied to a new entry named “Windows 7 diff”. In step 05 you have to look for the new entry “Windows 7 diff” and Copy & Paste the identifier in step 06 and 07. In step 06 and 07 the correct parameters for ‘device’ and ‘osdevice’ will be filled in. Check the newly created “Windows 7 diff” entry with bcdedit /v

Take care of above notation, because there are some inconsistencies with the entry that is used for a normal VHD. With a normal VHD ‘device’ uses the notation device file= and with a differencing VHD we have to use device vhd=. With a normal VHD a drive letter is used, with a differencing VHD the word locate is used. A drive letter should have worked here also, but I did not manage to get that to work.

I don’t know if above inconsistencies are in fact well over thought choices by Microsoft, but I have the feeling that this is because of using beta software. With bcdedit /? /formats you get a little more information but it doesn’t give an explanation about the difference between the formats. I tried many other combinations but above screenshot is the only one found 100% working.

Merge differencing VHD

If you tried something out in a differencing VHD and you are satisfied with the result then you can merge this information in the parent VHD. You might have created a long differencing VHD chain, you can specify the depth to which you want to merge.

01 boot from Windows 7 DVD or USB
02 Shift-F10 for a command prompt
03 dir C: (or D: E: etc.) to see where your VHD-directory has gone
04 diskpart
05 select vdisk file=c:\vhd\win7-diff.vhd depth=2
06 merge vdisk depth=1
07 exit

In step 05 you have to select the differencing VHD with a depth greater than or equal to the depth of step 06. In this example we merge one level back.

Delete above experiments

Are you ready testing and do you want to get rid of the obsolete boot entries? Start a command prompt with Administrator credentials and delete them with bcdedit /delete {identifier-of-entry-to-be-deleted} Delete the physical VHD file(s) from your hard drive and everything is gone without leaving a trace.

Read More