I could list all the reasons I think the iPad + Citrix are a great fit for healthcare, but it may be more meaningful coming directly from Physicians and IT Pros in the heathcare industry. This is a sample of what has been shared on the blogs when we asked what would Citrix Receiver for iPad be used for.
Dr. Paul Altmann says:
” Chris, the combination of Citrix and the iPad will, I am sure, be a huge success in the healthcare setting where the form factor of the iPad makes it the best all round device to access medical records in real time as clinicians care for their patients.Specifically, I am looking forward to showcase this for Cerner Millennium users who routinely access the application over Citrix.
There will be many other settings where the iPad, which is the first really decently sized, light, with good battery life “thin client”, will become very popular.
Dr Paul Altmann
Clinical Director – Health Informatics – NHS South Central & Oxford Radcliffe Hospitals NHS Trust
Consultant Nephrologist – Oxford Kidney Unit The Churchill – Oxford OX3 7 “

.. says:
“I would love to be able to use citrix on an iPad.  I currently use Citrix to log into our hospitals EMR, Epic, from home.  Being able to do so both at home and even in the hospital would be awesome. “

..says:
“So Are you saying that I would be able to use my GE Healthcare Centricity EMR Application from the Ipad? We connect to it using XenApp. This is really the only thing holding me back from getting an iPad is that whether I would be able to run my EMR for work.

..says:
“Please tell us you are working on a citrix client for the IPad.  It will be so “revolutionary” if you have one ready by the time the IPad is available. Physicians will love to use an IPad to handle their Electronic Medical Records at bedside, exam rooms.”

“Chris Smith says:
Yes, I think this would be fantastic. Many EHR (electronic health record) applications have developed stylus-driven interfaces for slate PCs (tablets with no keyboard option), so touch interface is a natural easy win for those already developed applications. Many of the EHR applications are also already deployed via Citrix, so this is a serious WIN WIN for Citrix to pursue… and as you mentioned, Citrix has already done quite a bit of work on the Citrix Receiver for the iPhone. This really does have so much more capability, now that you have the larger screen.
Also, multi-touch is supported in Windows 7, so it will be interesting to see how the XenReciever can interact with the Win7 host operating system environment, or even hosted application environment, but having the Receiver bridge that gap in the user experience via the iPad would be amazing!”

..says:
“I work for a health care provider and this could be huge. It turns the iPad from an interesting toy, to potentially powerful tool for business”

Todd Bruni says:
“Being in a large Healthcare environment I also see this device as having huge potential. First for ARRA/Hitech initiatives such as CPOE, BMV, Physician Documentation, etc physicians, clinicians, and/or nursing are going to want, need, demand mobile devices. As multiple people have pointed out one of those devices are tablets. The cost of those devices intended for Healthcare are extremely expensive (Motion Computing, etc).  Second, as people have pointed out protecting patient data is a requirement.  That is one of the beauties of desktop virtualization whether its hosted shared desktops or hosted dedicated desktops that data stays in the data center.  Finally organizations need to hit meaningful use in the not so distant future. Most of the large EMR vendors are not web-based today and organizations have to start taking steps now to meet the meaningful use timelines. That means these applications are client based today which is another reason to do desktop virtualization now until the ISVs solutions are ported to the web.
So how does this wrap back around to this device? Any device that is going to help healthcare organizations start taking steps now to adopt desktop virtualization, mobility, extend battery life, and move data into the datacenter without having to spend $2k on a tablet, $3k on cart solution is a great candidate. Being able to purchase 4 or 5 of these devices at the cost of one tablet makes it very intriguing. Add a docking station with keyboard and mouse for $40-50 in key locations and now you don’t have to worry about real estate on the floors (another huge healthcare issue) and the device becomes easy to stop and make updates to your EMR.
Finally, I don’t remember who said it but I completely agree with whoever said that we won’t know any of this until we get these devices into the clinicians hands we won’t know.”

..says:
“Already have XenDesktop environment pushing around 20 desktops using Nextgen out to several medical clinics in my area. Was able to get budget money for purchasing 5 iPads as a demo in less than 2 minutes. Will be an interesting demo as I have connections to several hospitals that are all looking into the EPIC Haiku Application also being developed with Keiser Medical Group in mind. A current rolling wireless cart with a WYSE Thin Client typically costs a Hospital in Oregon $20,000 after we did our full ROI 2 years ago. Interesting what happened in 2 years! “

Checkout the Heathcare IT Community site http://community.citrix.com/p/healthcare

Learn how to make the iPad work for your healthcare organization at Citrix Synergy. 

In an effort to finish publishing the PowerShell scripts I use for scalability testing, today’s GenVMs.ps1 PowerShell script demonstrates how to create basic virtual machines on Microsoft Hyper-V 2008 R2 hosts through the SCVMM PowerShell interface. The exciting part about today’s script is that when combined with the scripts I have previously released on this blog, it can be used to almost completely replace all the functionality of the XenDesktop Setup Wizard. The only thing left would be to create the Desktop Group, (which is on my list to automate but I have not got to that yet), in the Delivery Services Console.

This PowerShell script does the following:

1. Gets the next available MAC address from the Hyper-V address pool.
2. Creates a default profile with a single processor, 1GB RAM, and boot order.
3. Creates a VM using the supplied base name with a legacy network adapter and a DVD drive.

GenVMs Syntax Usage: GenVMs.ps1 VMTargetHost VMBaseName NetworkName LocalVMStoragePath NumberToCreate StartingAt Where: VMTargetHost= The Hyper-V host that will have the VMs created on it. VMBaseName= The base name for the virtual machines created. This name will have 00-99 appended to it. NetworkName= The name of the Hyper-V network to assign to the Legacy network adapter. LocalVMStoragePath= The path local to (or appears local to in the case of a CSV) the VMTargetHost. This is the path where the VM configuration files and the .BIN memory save-state file will be created. NumberToCreate= The number of virtual machines to create. Must be between 1 and 99. StartingAt= The starting number for the virtual machine incremental counter. This number plus the NumberToCreate should not exceed 99. Example: .\GenVMs.ps1 “HOST01″ “HVDesktop” “External” “E:\Hyper-V” 50 1 The example above will create desktops named HVDesktop01 – HVDesktop50 on HOST01 and the VM configuration files will be stored in HOST01′s E:\Hyper-V folder.

# Purpose:    Generate up to 99 virtual machines using the command-line parameters supplied
#             for customization of the new virtual machine.
# Date:       22 July 2010
# Author:     Paul Wilson (no implied or expressed warranties)
# Notes:      The script only creates VMs on a single host. To create VMs on multiple hosts
#             run multiple instances of the script from a batch file or create an outer loop.
#             The LocalVMStorage path must exist or the script fails. I have not added any
#             data validation checks to the script.

# Parse the command-line and verify the 6 required parameters are present, if not display usage info
if ($args -eq $null -or $args.Count -lt 6)
{
    write-output "Usage: GenVMs.ps1 VMTargetHost VMBaseName NetworkName LocalVMStoragePath NumberToCreate StartingAt"
    write-output "Example: .\GenVMs.ps1 ""HOST01"" ""HVDesktop"" ""External"" ""E:\Hyper-V"" 50 1 "
    exit 1
}

# Get the name of the SCVMM server we are running this on. The VMM server could be passed as a parameter as well.
$VMMServer = Get-VMMServer -Computername "localhost"

# Place the command-line parameters into named variables for later use.
$VMHost = $args[0]
$VMBaseName = $args[1]
$NetworkName = $args[2]
$VMPath = $args[3]
$VMCount = $args[4]
$StartCount = $args[5]
$EndCount = $StartCount + $VMCount - 1

for ($i=$StartCount; $i -le $EndCount; $i++)
{

    # Create a job group id to link the items together and create them as a group with the New-VM command

    $JobGroupID = [System.Guid]::NewGuid().ToString()

    # Get a MAC Address from the pool of available MAC addresses on the server. (Alternatively a MAC address could be assigned here.)

    $PooledMACAddress = New-PhysicalAddress -Commit

    # Get a network object for creating the network adapters

    $VNetwork = Get-VirtualNetwork | where {$_.Name -match $NetworkName -and $_.VMHost -match $VMHost}

    # Create a Virtual Legacy Network Adapter required for PXE booting with Provisioning Services

    New-VirtualNetworkAdapter -JobGroup $JobGroupID -PhysicalAddressType Static -PhysicalAddress $PooledMACAddress -VirtualNetwork $VNetwork

    # In case PXE booting will not be required or a second synthetic adapter the following line can be uncommented

    # New-VirtualNetworkAdapter -JobGroup $JobGroupID -PhysicalAddressType Dynamic -Synthetic -VirtualNetwork $VNetwork

    # Create a virtual DVD

    New-VirtualDVDDrive -JobGroup $JobGroupID -Bus 1 -LUN 0

    # Create a new Hardware Profile for a XenDesktop and set the default values or use the existing profile.

    $HWProfile = Get-HardwareProfile | where {$_.Name -eq "XD4Profile"}

    if ($HWProfile -eq $null)
    {
        write-output "Hardware profile not found. Creating a default profile."
        $HWProfile = New-HardwareProfile -Owner "XD4\Administrator" -Description "Hosted XenDesktop" -Name "XD4Profile" -CPUCount 1 -MemoryMB 1024 -BootOrder PXEBoot,IDEHardDrive,CD,Floppy
    }

    # Create the Virtual Machine and assign the VM Name. This only works up to 99 virtual machines.
    if ($i -lt 10)
    {
        $VMName = "{0}0{1}" -f $VMBaseName, $i
    }
    else
    {
        $VMName = "{0}{1}" -f $VMBaseName, $i
    }

    New-VM -VMMServer $VMMServer -Name $VMName -VMHost $VMHost -Path $VMPath -HardwareProfile $HWProfile -JobGroup $JobGroupID -RunAsynchronously -RunAsSystem -StartAction NeverAutoTurnOnVM -StopAction TurnOffVM
}

As mentioned earlier, this is a basic script and is meant to provide an example of how to create virtual machines on Hyper-V. This script could easily be modified to create VMs with different CPU/RAM requirements or even include the write-cache drive for Provisioning Server implementations as described in my previous blog PowerShell Scripts for XenDesktop Part 2.

In fact, if you run multiple instances of GenVMs.ps1 followed by copyVHD.ps1 from Part 2 the machine creation can be run in parallel (rather than serially) significantly reducing the deployment time over the XenDesktop Setup Wizard. Once the machines are created, use either GenPVSFile.ps1 from Part 3 or GenPVSMCLI.ps1 from Part 4 to load the machine and MAC address information into the Provisioning Services database. The final step is to return to the Delivery Services Console and create the desktop group.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

This is the second blog in a two-part series to respond to the remaining unanswered questions from my Citrix, Microsoft, HP: Best Practices for Scaling Virtual Desktops webinar on June 17, 2010. I covered the first half of the questions in XenDesktop Scalability Q&A Part 1. Some questions with similar content have been combined into a single question and others have been adjusted for typing errors.

Q: Can I get a podcast of this audio?
A: Yes. You can replay the webinar by clicking here though registration may be required.

Q: This lab infrastructure looks quite impressive but what would be the price tag on it? What would the initial investment be?
A: Unfortunately I do not have an answer for this question. I did ask that question while I was at HP and they told me that I would have to contact my HP sales rep to get a quote. I will say that HP, Microsoft, and Citrix have recently teamed up to help you jumpstart your VDI implementation, including discounted licenses and implementation services. You can check out the Activate and Ignite offers by clicking here. Also, HP has released a whitepaper on a building a single rack VDI implementation that supports up to 1,000 users. You can find more about this configuration by downloading the Whitepaper – HP Reference Configuration for Citrix XenDesktop directly from HP’s website.

Q: What are the advantages of for Citrix Provisioning Server vs. other provisioning solutions?
A: I cannot speak for other provisioning solutions, so I am just going to share the advantages of Citrix Provisioning Services (PVS). The primary advantage of Provisioning Services is the ability to save storage costs. With PVS, you can create a single desktop image that can then be streamed over the network to the guests using the PXE boot protocol. The guests can be diskless, though for best performance we usually recommend a 2-3 GB local disk to function as a write-cache. The storage savings comes from only needing a write-cache drive which represents a fraction of the size needed for a full VHD. For instance, a normal virtual desktop deployment of 100 desktops each with a 20GB Windows 7 image would require about 2000GB of costly SAN storage. With PVS, the storage can be reduced to a single 20GB Windows 7 image and 100 2-3GB write cache disks or about 320GB, which could be local or SAN storage.

The second advantage I see is the ability to upgrade or revert with only a simple reboot of the guest. Since a single image can be used across multiple virtual desktops, updates need only be performed in one location. Then virtual desktops automatically pick up the most current image upon reboot. If for some reason that image fails to perform, the administrator can easily revert to a previously working image and reboot the guest. Factor in the reduced overhead on the host’s CPU and disk subsystems, (because the disk reads are now coming over the network), and the solution improves guest performance significantly.

Q: What metrics do you monitor to identify bottlenecks within Provisioning Server? Are the metrics the same between physical and virtual Provisioning Server?
A: Really good question. Normally, you monitor the same metrics you would for any other server, since the bottleneck could be at the CPU, RAM, Disk, Processor or Network level. However, that said, you will find that the network is by far the most utilized resource, so watching the Bytes Sent/sec performance counter is where I start. If your write-cache is on the server-side (instead of client-side) then you will also need to watch the Bytes Received/sec, the Processor % Idle Time, and the Current Disk Queue length. From the test results I have seen I would say the second most utilized resource is the CPU, so watch that one if you do not have a beefy box.

To give you an idea, for the 3500-desktop run we had three BL460C blades each with 48GB RAM, dual Nehalem processors and 4GB of network bandwidth. The network bandwidth was reaching 3GB when booting up all 3500 servers. The processors were at 50% idle. I had only one vDisk image so the current disk queue length averaged slightly over 0 and the server reported 45GB of available RAM.

Q: What metrics do you monitor to identify bottlenecks within the Desktop Delivery Controller?
A: As stated earlier, bottlenecks could appear in any resource, so I watch key indicators across the board. That said, the resource most likely to be the bottleneck with the Desktop Delivery Controller is the CPU. Watch the CPU %Idle time and the CPU %Processor time for the Citrix services, such as CdsPoolMgr on the Pool Master and both CDSController and IMASrv on all the member servers. Also watch the Context Switches and Processor Queue Length for general processor health.

Q: Can you provide the formulas used in the IOPS calculator spreadsheet?
A: No, but I am planning on releasing a copy of the spreadsheet in Q3 so watch my website for updates.

Q: What is the expected completion date for the whitepaper?
A: Currently the draft is circulating for review. Provided the reviews are completed in a timely manner and the document doesn’t have any major flaws, the plan is to release it by the end of Q3.

Q: When will offline virtual desktops be available?
A: Technically speaking, you can have offline virtual desktops today with XenClient, which is free. You can download it here.

Q: What method should I use for sizing XenDesktop?
A: In a general sense, Citrix and other vendors provide sizing guidelines. Some vendors, such as HP even have sizing tools available for download to help you get the best hardware fit for your needs. I believe the best method is probably to do a pilot with your power users. If you are serious about VDI, the best approach is to take and build a small pilot environment. The results of the pilot will give you an idea of what the performance expectations of the virtual desktop should be as well as a taste for how it will fit into your environment. Then you can take your performance data and correlate that with published VDI data on the same hardware, from there you can extrapolate what hardware you will need.

For instance, say you build Windows 7 desktops on a BL460C with 64GB RAM and Nehalem processors and choose Hyper-V as your hypervisor. At the end of the pilot you may determine that the optimal number of users is 50. If published results for the same configuration show an optimal number of users on a BL460C running a medium LoginVSI workload is 75, then you know that your workload requires about 50% more capacity than the medium LoginVSI workload. At this point, you can use the LoginVSI medium workload results on any hardware or hypervisor and adjust the capacity by 50% to get your number on that same configuration.

Q: Without seeing lab results yet, what is the largest number of virtualized desktops I can expect to run concurrently? What is the real-world experience vs. the lab?
A: Since this question is not specific as to the bounds of the concurrency I will presume it is referring to concurrent desktops on a single server. Essentially, the number of concurrent desktops that you can run on a single server depends primarily on your user workload. Generally speaking, the LoginVSI medium workload that we use in the lab is purely for comparative purposes and is unlikely to represent your actual user workload. What LoginVSI does do is give you an idea of what the hardware is capable of supporting in a specific configuration. I have seen the number of desktops for a single server range from 30 to over 120 with the limiting factors usually being available RAM or processor.

Q: Would one expect to see the same results regardless of the hypervisor being used or will that make a difference? Would we expect to see similar performance/numbers if we used vSphere4 or XenServer Enterprise/Platinum instead of Hyper-V?
A: I believe I answered this one during the webinar, but I will reiterate my position again. I believe hypervisors are now becoming more of a commodity with respect to performance and scalability with the key differentiators being features such as migration, snapshots, etc. Each hypervisor has its areas of focus and some may perform better than others in certain configurations. Overall I would venture to say that I expect similar scalability numbers (say within 10% tolerance) on the same physical hardware when comparing hypervisors.

Q: In Active Directory – the more global groups an ID is associated with the larger the ID bloat becomes. Today there is a limit on the size of the ID file which also limits access to the server farm. Today Microsoft doesn’t have any way of correcting this issue. Do you know of a way to get around it?
A: Unfortunately, no. Microsoft Kerberos tokens have a maximum limit of 1024 SIDs, (less in some circumstances depending on the length of your AD domain’s FQDN), which when exceeded prevents user logon because all group memberships cannot be evaluated. The only solution at this point is to reduce the amount of group memberships. Microsoft is aware of this issue and has provided guidance and best practices to help limit the exposure. You can download their guide from the Microsoft website but I cannot provide a better solution at this time.

That concludes the unanswered questions from my webinar. I hope you find the answers helpful. If I misunderstood your question, feel free to clarify it as a comment below.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

Two days ago I provided a PowerShell script that could be used to generate an import CSV file for Provisioning Services (PVS). However, after importing the devices, a vDisk still needed to be assigned (if you didn’t configure a template) and more importantly, an account still needed to be created in Active Directory for each device. These extra steps increased the complexity of the import process.

I got to thinking that the MCLI command-line interface could be used to do all three tasks, but the PowerShell script would have to generate all the MCLI commands necessary for each desktop import. I had a bit of spare time, so I sat down and modified the earlier import script into a new PowerShell script that outputs a file of MCLI commands for the desktop import. As with the prior script, this one should be run from the SCVMM server that manages the XenDesktops that you are importing into Provisioning Server.

This new PowerShell script creates a CMD file that contains three MCLI commands for each desktop. The commands are as follows:

1. Adds the device to the configured device collection
2. Assigns the vDisk specified on the command-line to the device
3. Adds the device to the domain

After the PowerShell script has successfully completed, the only step left is to take and run it from the %ProgramFiles%\Citrix\Provisioning Server folder on one of the provisioning servers. The MCLI commands should then execute sequentially the three commands listed above for each desktop.

GenPVSMCLI Syntax Usage: GenPVSMCLI.ps1 SiteName CollectionName Description StoreName vDiskName CmdFileName VMMatchCriteria [OUName] Where: SiteName=Provisioning Services Site where the device collection resides CollectionName=Provisioning Services Collection where the devices will be created Description=Generic description added to the devices. All devices will have the same description StoreName=Provisioning Services store name where the vDisk resides vDiskName=Provisioning Services vDisk name to assign to all the devices imported CmdFileName=File name that will contain the MCLI commands when the script completes VMMatchCriteria=Name match criteria for which guests to include in the file OUName=Name of the Active Directory OU where the computer accounts should be created. The default is Computers if none is specified. Example: .\GenPVSMCLI.ps1 “Dell” “XenDesktops” “XD Desktop” “Local Disk” “Win7Base” “c:\PVSMCLI.cmd” HVDesktop “XenDesktop/VMs” The example above will create a file called PVSMCLI.cmd that will have all the MCLI commands for hosts matching the name HVDesktop (HVDesktop1, 23HVDesktop, etc.) in it to add devices to the XenDesktops device collection in the Dell site. The vdisk Win7Base found in the store called “Local Disk” will be assigned to all the devices imported and the computer accounts will be created in the VMs OU found in the XenDesktop parent OU.

# Purpose:    Create a MCLI cmd file to add devices to Provisioning Services, assign a vDisk
#             and add the device to Active Directory. The cmd file can then be executed from
#             any Provisioning Services server.
# Date:       1 July 2010
# Author:     Paul Wilson
# Notes:      The file may need to be opened and saved in ANSI format on some computers.
#             This script automatically appends information to any existing file in case you
#             need to run the command multiple times with different match criteria

########################################################################################################################
# Special     Organizational Unit to add the Device(s) to is an optional parameter.                                    #
# Use         If it is not specifed, the device is added to the builtin Computers container                            #
# Notes       Child OU's should be delimited with forward slashes, e.g. "ParentOU/ChildOU".                            #
#             Special characters in an OU name, such as '"', '#', '+', ',', ';', '>', '=', must be                     #
#             escaped with a backslash. For example, an OU called "commaIn,TheMiddle" must be specified                #
#             as "commaIn\,TheMiddle". The old syntax of delimiting child OU's with a comma is still                   #
#             supported, but deprecated. When delimiting with commas,the child OU comes first, e.g. "ChildOU,ParentOU".#
########################################################################################################################

# Parse the command-line and verify the 7 required parameters are present
if ($args -eq $null -or $args.Count -lt 7)
{
    write-output "Usage: GenPVSMCLI.ps1 SiteName CollectionName Description StoreName vDiskName CmdFileName VMNameMatches [OUName]"
    write-output "Example: .\GenPVSMCLI.ps1 ""Site"" ""Collection"" ""XD Desktop"" ""Local Disk"" ""Win7Base"" ""c:\PVSMCLI.cmd"" HVDesktop ""ParentOU/ChildOU"" "
    exit 1
}

# Place the command-line parameters into named variables for later use.
$SName=$args[0]
$CName=$args[1]
$DString=$args[2]
$StName=$args[3]
$VName=$args[4]
$CmdFName=$args[5]
$VMNameMatches=$args[6]
$OUName=$args[7]

# Connect to the local server as the SCVMM host to process the PowerShell commands
$VMMServer = Get-VMMServer -Computername "localhost"

# Retrieve a list of all the VMs that match the name matching criteria supplied and sort them by name
$AllVMs = Get-VM | where { $_.Name -match "$VMNameMatches" } | sort Name

# For each VM found the loop below does the following:
# 1. Locates the MAC address of the primary network adapter
# 2. Appends to the cmd file supplied the MCLI command-line to add the device with the appropriate information.
# 3. Appends to the cmd file supplied the MCLI command-line to assign the provided vdisk to the device.
# 4. Appends to the cmd file supplied the MCLI command-line to create the computer account in the domain.

foreach ($vm in $AllVms)
{
    $nicDetails = Get-VirtualNetworkAdapter -VM $vm
    $MacAddr = $nicDetails[0].PhysicalAddress
    $AddString="MCLI Add Device -r deviceName={0} collectionName=""{1}"" siteName=""{2}"" description=""{3}"" deviceMac={4} bootFrom=1" -f $vm.Name, $CName, $SName, $DString, $MacAddr
    $AssignString="MCLI Run AssignDiskLocator -p deviceMac={0} diskLocatorName=""{1}"" siteName=""{2}"" storeName=""{3}"" " -f $MacAddr, $VName, $SName, $StName
    if ($OUName -eq $null)
    {
        $DomainString="MCLI Run AddDeviceToDomain -p deviceMac={0}" -f $MacAddr
    }
    else
    {
        $DomainString="MCLI Run AddDeviceToDomain -p deviceMac={0} organizationUnit=""{1}"" " -f $MacAddr, $OUName
    }
    write $AddString | out-File $CmdFName -Append
    write $AssignString | out-File $CmdFName -Append
    write $DomainString | out-File $CmdFName -Append
}

Now, I have noticed that when adding hundreds of devices at a time that the domain controller gets busy and the AddDeviceToDomain command sometimes fails. I suggest for large deployments that you pipe the output to a text file and then later review it for possible failed commands. Re-running the failed commands should be sufficient since they are mostly independent of one another. The only exception being the Add Device command must succeed or the other two will fail.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

This blog is to respond to questions from my Citrix, Microsoft, HP: Best Practices for Scaling Virtual Desktops webinar on June 17, 2010. I received 22 questions during the webinar and unfortunately did not have time to answer them all. I will cover the first half of them in this blog and address the remainder in a follow-up blog. Some questions with similar content have been combined into a single question.

Q: Do you have a link to the specific entry on your blog about your experience with the issues between NIC teaming drivers and the Hyper-V role?
A: Yes, though technically it is not on my blog, but on my XenDesktop with Microsoft Technologies website. Under the Other Resources section you will find the entry “How-to Guide for HP NIC Teaming Software and Microsoft Hyper-V”. Just follow that link.

Q: What would you estimate the ratio of virtual machine to server CPU core to be?
A: It depends mostly on the processor. My experience with Intel Nehalem processors is that the maximum VM Density per core is around 11 for a medium workload. However, I would not recommend running at 11 for that workload, I would probably plan for 9-10 per core to leave some headroom for burst capacity. Keep in mind also that those numbers are taken without an anti-virus solution in place.

Q: Do you have best practice hardware and software setups for 50-100 user increments that are scalable for adding additional 50-100 user blocks that can be downloaded?
A: Not at this time. Citrix Consulting Solutions is currently working on a concept document that covers the creation of a small scale architecture that can be repeated. That document is in the final stages of review, so it should be released in the near future.

Q: From what I know we can create two different types of profiles – standard (for everyone) and dedicated. The dedicated one gives a users “administrator” privileges to make permanent changes to their desktop that are persistent. For a “standard” image, how much information follows a user on their profile from session to session as they log on and off multiple times?
A: Good question. What you are actually referring to is what we call vDisks for Provisioning Services. The vDisks are “golden master” images that are shared or private to a virtual machine. When a vDisk is in “private” image mode, all changes are permanent to the VHD. The “standard” image is considered “read-only” and all software installed is lost when the virtual machine is rebooted. The standard mode is used for creating pools of desktops that are available to service any user. The amount and type of information that follows a user between sessions is dependent on how profiles are managed. The key to deploying this successfully is using profile management software that can redirect the user data folders to a network location or save off the data in a roaming-profile type scenario. In both image modes, the user can be configured to be either a local administrator or just a local user, similar to any other workstation on the network.

Q: How different would the architecture be in a combined scenario of XenDesktop and XenApp?
A: That is the beauty of using XenDesktop Enterprise or Platinum editions, they come with XenApp and the only difference is the addition of XenApp servers. The XenApp farm can leverage the existing License Server, database server for the hosting the farm (though it will be a different farm), and even the same Web Interface servers. In fact, most XenDesktop deployments today include XenApp. Using XenApp provides the advantage of offloading the processing for resource-intensive applications and also helps reduce the licensing costs of applications that are not necessary for all users to have installed.

Q: How many virtual desktops could be supported with a DL380 G6 32GB RAM and 8 cores?
A: Let start by saying “it depends” probably more on the user workload and the SAN/Local storage available than on the RAM and Processor power. I cannot tell you how many desktops you could get in your environment, but I can tell you what I have seen with regard to limitations. The processors will not be a limiting factor because Windows 7 core density on a G6 (Nehalem class processor) will be around 10:1, so 8 cores would about 80 machines. Your primary limiting factor appears to be the RAM. With only 32GB RAM you could get a maximum of about 30 Windows 7 desktops (1 GB RAM) or maybe 60 Windows XP (512MB) on Hyper-V. A DL380 G6 supports up to 8 SFF drives, so the local storage could be used to host guest virtual hard disks. Once again though, it all depends on your user workload.

Q: Was that Hyper-V on server core?
A: No. We used the full Windows Server 2008 R2 Hyper-V version instead of server core. The primary driver for this decision was the need to obtain detailed performance metrics on the host servers and correlate that data with our internally developed test harness, called STAT. Unfortunately, the STAT agent responsible for the metric collection requires a GUI install which would not work on server core. A nice benefit of not using server core was of course that I didn’t need to figure out the script commands for installing and configuring HP NIC teaming drivers.

Q: Can a presentation be prepared or at least a comparison between Hyper-V and ESX4i (VSphere)?
A: Yes. I am currently planning a similar topic for my Q3 webinar. The VMWare EULA prevents any direct comparisons or performance results from being communicated, but I plan to cover the best practices for running guests on the three hypervisors supported by XenDesktop: XenServer, Hyper-V and VMWare VSphere.

Q: Which FlexCast model applies to your testing and scalability numbers?
A: The model that I used is considered the “Hosted VDI” model where a full VM is running on a Hyper-V host. However, technically speaking, it includes the “Streamed VHD” model, since the VHD for the pooled desktops was getting streamed to the virtual desktops running on the host system.

Q: The response times are based on local LAN-based users, correct?
A: Yes. However, since the response times are calculated by Login VSI from within the XenDesktop session, they would be the same no matter where the desktop is accessed from. For WAN users you would need to adjust for the latency on the line.

Q: Seems like Citrix talks a lot about deploying on Hyper-V. Is there a reason why this is done on Hyper-V instead of using XenServer (or even VMWare)?
A: Good Question. The answer is that we perform these tests on all hypervisors. It just turns out that I am the XenDesktop on Microsoft architect, so I volunteered to be the one that did the Hyper-V testing. We do have some scalability test results for other hypervisors on our Citrix eDocs website. Once there choose XenDesktop >> XenDesktop 4 >> XenDesktop Scalability Guidelines. We are continually testing XenDesktop with all supported hypervisors and normally make that information public as it becomes available.

That concludes the first round of unanswered questions from my Scaling XenDesktop webinar. The rest should be posted within the next few days. I hope you find the answers helpful. If I misunderstood your question, feel free to clarify it as a comment below.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

Today I want to provide a PowerShell script that can be used to export information from a XenDesktop Hyper-V installation and import it back into the Provisioning Services (PVS) console. This script is useful when you are not using the XenDesktop Setup Wizard and are creating the virtual machines manually. Exporting and importing is much quicker than manually adding each guest VM machine name and MAC address to the console.

The PowerShell script should be run from the SCVMM server that manages the XenDesktops that you are importing into Provisioning Server.

Syntax Information Usage: GenPVSFile.ps1 SiteName CollectionName Description ImportFileName VMMatchCriteria Example: .\GenPVSFile.ps1 “Dell” “XenDesktops” “XD Desktop” “c:\PVSImport.csv” HVDesktop The example will locate all VMs with a name that matches HVDesktop (HVDesktop1, 23HVDesktop, etc.) and generate a CSV file called PVSImport.csv. When imported via the PVS console, the devices will go into the XenDesktops collection for the Dell site.

# Purpose:       Create a CSV file that can be imported by Provisioning services
# Date:          14 April 2010
# Author:        Paul Wilson
# Notes:         The CSV file may need to opened and saved in the ANSI format on some computers.
#                This script automatically appends information to any existing file in case you need to
#                run the command multiple times with different match criteria.

if ($args -eq $null -or $args.Count -lt 5)
{
    write-output "Usage: GenPVSFile.ps1 SiteName CollectionName Description ImportFileName VMMatchCriteria"
    write-output "Example: .\GenPVSFile.ps1 ""Site"" ""Collection"" ""XD Desktop"" ""c:\PVSImport.csv"" HVDesktop "
    exit 1
}
# Pulls the VM Name Match criteria off the command-line
$VMNameMatches = $args[4]

# Connects to the local SCVMM Server
$VMMServer = Get-VMMServer -Computername "localhost"

# Finds all matching VMs and sorts by their machine name
$AllVMs = Get-VM | where { $_.Name -match "$VMNameMatches" } | sort Name

# The following loop gets the MAC address of the primary NIC then writes
# that output to the CSV file along with the other fields required for the PVS import
# most of which were supplied as parameters on the command-line.

foreach ($vm in $AllVms)
{
	$nicDetails = Get-VirtualNetworkAdapter -VM $vm

	$csvString = "{0},{1},{2},{3},{4}" -f $vm.Name, $nicDetails[0].PhysicalAddress, $args[0], $args[1], $args[2]
	write $csvString | out-File $args[3] -Append
}

After you have the file, you have two options for importing the data into Provisioning Server. Before doing either, the best approach is to configure a default template for the collection and set the appropriate vDisk for that template. This way you will not later need to go back and assign a vDisk to all the devices. You can use the PVS Administrator’s guide to obtain instructions on how to create and assign a device template.

Using the GUI you can select a device collection, then right-click and choose Target Device >> Import Devices… from the context menu as shown in the screen shot below.

Alternatively you can use the MCLI command-line utility that comes with Provisioning Server. The MCLI commands must be run from a Provisioning server at this point. You can find MCLI in the %ProgramFiles%\Citrix\Provisioning Services folder. The command-line for importing looks like this:

MCLI run importdevices -p filename=\\server\share\pvsimport.csv copyTemplate=1

Remember after you finish importing all the MAC addresses be sure to add them to Active Directory. You can do this by selecting all of the devices, right-clicking on them and choosing Active Directory >> Create Machine Account… from the context menu as shown below.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

Electronic Medical Records (EMR) implementations have their own, unique challenges. Healthcare organizations are concerned with selecting a vendor, complying with a myriad of regulations, and basically transforming the way healthcare is delivered to their patients.
Given the transformative nature of an EMR implementation, virtualization is often just a side thought for health CIOs. Therefore, I’d like to shed some light into the topic and share my personal top 5 reasons to pursue this topic further- starting with the centralization of medical records data.
For a quick definition of the term itself, please refer to yesterday’s blog.
I assume that the backend database for your electronic health records reside in a single, centralized datacenter. Through global server load balancing, you may have already implemented site-to-site redundancy, but that’s beside the point for today’s discussion.
So, traditionally, you would have rich client applications or web browsers on the user’s endpoint to consume and manipulate the medical records data. This automatically implies that a lot of health data moves to and from the datacenter and often to remote locations where it is challenging to maintain a tight grip on security.
Application or Desktop Virtualization can solve that problem. Both of these techniques move the client software piece (or web browser) to the datacenter, where it executes securely inside your facility. The health data never even leaves the datacenter. The user interaction happens via a secure, high performance protocol (such as Citrix’ HDX in the XenApp and XenDesktop product lines) and gives the user a snappy interaction with the software, while only exchanging screen updates and keyboard/mouse events between the end user and the datacenter. Additional data streams pertaining to peripherals, printers, USB devices, scanners, and client hard drives are possible, but can easily be disabled to promote further security.
No data ever makes it to the end point, and therefore reducing the risk of HIPAA/HITECH covered security breaches. In addition, user sessions can be audited to establish an independent trail of information in case the regulators or courts require a closer look.
If you’re curious, I encourage you to check out Dan Feller’s Ask the Architect site. Dan has a wealth of information on desktop and application virtualization and associated whitepapers and reference architectures.
Florian Becker
Twitter: @florianbecker
Virtualization Pulse: Tech Target Blog
Ask the Architect – Everything Healthcare

The following is a blog I posted on my “other” site – Virtualization Pulse, hosted by Tech Target. Most readers on these pages are already very knowledgeable, so please forgive the simplistic view. In the near future, I will publish additional blogs on virtualization and specifically focus on the the healthcare IT space. Consider this one a relatively simple level-set for the audience. Enjoy.
———————————

Given that there are a lot of incentives associated with the adoption of Electronic Medical Records, medical CIOs and their teams are inundated by vendor messages these days. Phrases like “Meaningful Use”, “HITECH”, “HIPAA” are on the forefront of everyone’s mind, but you may also hear about virtualization. Given that there is still some confusion on the topic, I’d like to clear a couple of things up:

“Virtualization” is a term that has been traditionally used in the context of server virtualization. The technology involved is often referred to as “Hypervisors” which basically allow a modern server with plenty of CPU and Memory resources to share those resources between multiple “workloads” or “virtual servers”. So, instead of having one physical server with 16 CPU cores and 128 GB of RAM, this server can often house 40-60+ individual workloads that act on your network just as if they were much smaller individual servers. The benefits are obvious. Today’s servers are relatively cheap to acquire and most server workloads don’t require nearly as many computing resources to do their job. IT departments can lower cost by running fewer physical servers, consume less rackspace, lower power consumption and cooling costs. Advanced virtualization solutions also allow for virtual servers to automatically move to a separate physical host in case of a hardware failure. The failover process is often seamless and therefore provides resiliency, but typically requires a separate, redundant storage area network for this to work on the fly. Workloads with less criticality can be moved in a semi-manual fashion where they are simply restarted on another physical host by the administrator.
Vendors in this space include VMware (vSphere), Citrix (XenServer), Microsoft (Hyper-V) and a number of other players.

Application Virtualization. This is another form of virtualization, which has virtually nothing to do with server virtualization (pun intended). In this model, an application (think about your office productivity suite, or your electronic medical records client) is installed on a central server and executes there. The user connects from their endpoint (PC, laptop, thin client devices, etc.) via a remoting protocol and essentially controls the application remotely. This can be done on the simple level with Microsoft Terminal Services and the RDP protocol, and on the higher end via specialized solutions such as Citrix XenApp (formerly known as Presentation Server or MetaFrame). The benefits are obvious. Applications can be centrally managed and IT support personnel would no longer have to touch an end users system to install or patch an application. All updates are performed on a few centrally located servers. This approach also has the advantage of the application being physically close to the backend data of the app (on a low-latency, high bandwidth network), which leads to faster execution of the app and much increased security as the data never leaves the datacenter. The only information that is exchanged between the end-user’s device and the central server are screen updates and mouse and keyboard events. The protocols also include the capability of conveying information such as audio, printing, USB device support etc. The performance is actually astonishing in many cases and the most demanding customers in the area of engineering run their complex design applications via Citrix XenApp.

Desktop Virtualization. This is the latest and greatest. Instead of executing just a set of applications in the datacenter, the industry is moving towards executing desktop operating systems in the datacenter and allowing users to connect to the desktops . One could write a whole book about desktop virtualization, so I am trying to keep it brief. Some vendors tout a “VDI” or “Virtual Desktop Infrastructure” model, where each user basically has their own, assigned, virtual desktop in the datacenter. This model moves the headache of desktop maintenance to a central location, but still encounters some of the same challenges associated with traditional desktop management (such as the need to patch multiple desktop instances and troubleshoot/fix corrupted or infected desktops).
More advanced models go towards a shared desktop image model, where each user connects to a brand new, pristine desktop operating system, which folds the applications and user settings into the desktop as the user connects. This has the advantage of ensuring the highest performance (after all, a brand new desktop always performs best) and can also cut down on the number of desktops to maintain. Having just one or a handful of desktop master images to patch and maintain for thousands of users provides great efficiency gains and cost savings.

So, let’s recap. Server, Application, and Desktop Virtualization are three distinct disciplines in healthcare IT and are important to understand. Don’t fall for the siren’s song and believe that a particular vendor who is good at one discipline is automatically an expert at the other virtualization disciplines.
Check back on these pages in the near future for my rundown on virtualization techniques for your EMR implementation.

Florian Becker
Twitter: @florianbecker
Virtualization Pulse: Tech Target Blog
Ask the Architect – Everything Healthcare

…No, I am not talking about the world-famous subway system in London, but rather like to pick up the topic by Dr. Philip Chase on the Physician’s view of an EMR. Dr. Chase describes how a recent visit to his physician revealed that the esteemed healthcare provider spent a lot of time typing Dr. Chase’s answers into an EMR application. The physician’s attention was divided between the patient and the computer system and the entire encounter had the appearance that the EMR itself interfered with the doctor – patient relationship; hence the “gap” between data acquisition and data entry.

Since there’s a lot of talk on EMR’s these days (one recent blog post describes the HITECH Anxiety), I figured it be a good time to reiterate some of the common sense EMR thoughts and best practices.
• Doctors don’t want to be IT admins. Correct. I don’t think they have to. Purely Internet-based EMR vendors use this tagline to entice providers to move all of their patient data to a hosting provider, but many physicians are more comfortable with on-premise solutions. Roughly 50% of office visits are delivered by 1-2 doctor practices. Like many other small business in all kinds of verticals, physicians can rely on other (often small) businesses in the IT / Computing world to setup a local system and support a locally running EMR. It’s “my computer guy” who takes care of installing, maintaining, patching, and backing up the systems in any small business, regardless of the industry. Action: Think about hosted vs. on-premise systems and pick the ones that you are most comfortable with.
• Usability is key. You don’t want your patients to stop seeing you, because the visits have become impersonal. Don’t focus more than 5-10% of your patient time looking at a computer screen. This will require discipline and some practice. Pick EMR software that lets you work from selection lists and templates rather than free text. Practice some typing (if that’s new to you) and have a vendor demonstrate the speed of documentation and order entry to you.
• Devices play a big role. Bigger than you think. Vendors bombard you with different options. Everything from regular office PCs, laptops, tablet PCs (including the Apple iPad), to computers on wheels (COWs) are options. Depending on your practice setup, one or more of these may fit. Here are some thoughts: Don’t set up your devices statically (that would require you to turn your back on the patient on occasion). If you go for wheeled devices, make sure they are not clumsy or blocking your space and movement in the practice. Ensure that wireless networks reach all your exam rooms and provide good signal strength. Consider a tablet device as you can carry it around. Be mindful of the device often occupying at least one of your hands that you won’t have avalailable to examine or treat the patient. Some devices with smaller form factors are said to fit in a lab coat. Try it before you buy! Consider the devices battery life and screen size. Action: Try the different devices in conjunction with the short list of EMRs you’re considering. Some vendors have specific user interfaces for mobile devices or iPads that improve usability when using a multi-touch interface.
• Multi-user environments pose special challenges. If you have more than 1 clinical user or running a group practice, consider the fact that physicians will physically move away from a device and into the hallway or next exam room. Unless you choose portable devices, consider fast log off and log on modalities and session roaming. The latter can be achieved through application and desktop virtualization, where your application executes centrally and the “terminals” in the exam rooms and hallways just provide interactive access to the application.
• Offsite usage. Nothing is more annoying than not having access to a system when you need it. Ensure that your system has secure offsite access built in. In most web-based EMRs , you should be covered. More elaborate systems may require app or desktop virtualization where the apps and data stay securely tucked away in the data center (or data closet, depending on your size) and allow your users to connect securely over the Internet to the user interfaces of the apps. Action: Discuss those options with your “computer guy” and your EMR vendor.

I plan on sharing more specific virtualization best practices with you in the upcoming weeks and months. Please let me know if there are specific topics you would like to hear about.

Florian
Twitter: @florianbecker
Ask the Architect – Everything Healthcare
Tech Target Blog – Virtualization Pulse

Computerworld posted an article titled E-Health and Web 2.0: The Doctor will tweet you now. The title made me cringe, to be honest. If any medical provider would communicate with a patient via facebook or twitter on patient related topics, we’d have an avalange of lawsuits on our hands. Thankfully, it is not that bad as the article cited above describes electronic communications between doctors and patients accurately. However, the slightly misleading title still leads me to believe that some clarification on web and social media is in place.

• Ever heard of email? It’s this killer app that spread from scientists to the rest of the world in the mid-to-late nineties. It’s not inherently secure, but there are systems that allow for secure communication and it is slowly being discovered by the healthcare world to allow patients and providers communicate with one another. Instant messaging also falls into this category and so is text messaging (txt is really a special form of telephony and we have been using that killer app for at least 50 years to communicate with our doctor). Sophisticated EMR vendors have implemented such capabilities into their systems. There are many, but Epic’s MyChart module comes to mind – for an idea on how it works, check out the various Group Health Seattle Ads: I actually only found a recent one here. Group Health Seattle implemented MyChart and secure patient to doctor communication in 2002/2003 – long before YouTube became mainstream, so I can’t find the original ads, which also shows you that this is nothing new. The key here is that patients and providers don’t use the “traditional” email systems that are often available for free by various providers on the Internet, but implement a system directly into the Electronic Medical Records app, which has the added benefit that the communication becomes part of the patient’s record.

• Twitter and facebook are still relatively new, and are certainly not intended for any kind of point to point communication, but rather for dissemination to larger groups or “Communities of followers”. Businesses (Joe’s Pizza as much as a doctor’s office, larger group practice, or large hospital) leverage twitter, facebook, MySpace, etc. to update their customers about things they deem important. Announcing new products or services, sending links of interest, or providing patient education on general topics are all things that lend themselves greatly to twitter and facebook. By the way, the same information can be effectively distributed via email lists, but twitter and facebook allow for customer controlled opt-in and opt-out. Both sides win – customers don’t get annoying unsolicited emails and business don’t have to manage email lists. Again, evem the direct message feature in twitter does not lend itself to securely communicate with patients, hence my introductory cringing at the beginning of this blog.

• Speaking of blogs….Blogs are also labeled “social media”. The idea is really nothing new. In the old days (by that, I mean the very old days in the mid 90s), we had to teach ourselves HTML, stand up a web site, and voila – we could get our thoughts and comments out on the web. In my mind, blogs are the great equalizer as they are very easy to use and provide the technical means to publish articles and opinions to the web (some are rants – actually, this blog could be described as a mild rant) . Blogs often allow for others to comment on the original article and that way get a nice discussion going. In healthcare, blogs play an important role as patients can discuss their own conditions with others (often anonymously by using screen names instead of their real names). This also allows for the sharing of information and the establishment of a support network. It’s the 2009 version of Fight Club without the hugging. Twitter and blogs often go together as bloggers leverage twitter to announce a new post to their community of followers. Healthcare providers can provide pro-active patient education via blog sites and use twitter to let their patients know that something noteworthy has been published.

So – none of these concepts are new or revolutionary in my mind. These are old technologies that either make the administration easier (blogs) or allow more user control when it comes to information blasts (twitter, facebook), or facilitate point to point communication (email, IM,txt). It goes without saying that both patients and providers must carefully consider their privacy (and the associated regulations) when using either of these media forms.

Thoughts? Comments? Please post them here.
Follow me on twitter: @florianbecker