866-764-TECH(8324) · Subscribe to Application Solution Providers, Inc.News FeedSubscribe to Application Solution Providers, Inc.Comments

If you’ve administered a XenApp or XenDesktop, you’ve had to go through the applications or desktops at some point and make manual modifications or check settings. However, you may never need to do that again – if you learn how to use PowerShell.

XenApp and XenDesktop now both support PowerShell, which replaces the aging MFCOM scripting that previously allowed control of Citrix farms. This allows you to manage almost any component that can be managed via the consoles.

Haven’t done PowerShell, or not comfortable with it yet? Check out my upcoming Ask The Architect webinar on XenApp & XenDesktop with Powershell.

Register for this webinar on Thursday, 15:00 GMT (10:00 AM EST)  at https://www1.gotomeeting.com/register/156454064.

Want to start learning now? Here are some great resources to get you started:

The debate still rages on, Hosted Shared or Hosted Virtual desktops.  This is probably one of the most common question I hear. So which is it? Hosted Shared or Hosted Virtual? 

Guess what? The answer, for once, isn’t “It Depends”.  The answer is “Yes”, you will mostly likely need them both. For those of you who aren’t sure what the difference is, it is pretty straightforward:

  1. Hosted Shared Desktops: A published desktop on XenApp. Users get a desktop interface, which can look like Windows 7. However, that desktop is actually being shared by every user on the server. Although we can configure restrictions and redirections to allow users to have a smaller impact on each other, there is still a risk. Many users to one desktop.
  2. Hosted Virtual Desktops: A Windows 7/XP desktop running as a virtual machine where a single user connects remotely. One user’s desktop is not impacted by another user’s desktop configurations. Think of this as one user to one desktop. There are many flavors for the hosted virtual desktop model (existing, installed, pooled, dedicated and streamed), but they are all located within the data center.

The big reason why people want to figure out if they need a hosted virtual desktop is because of scalability, which equates to money. I can get 100-200 concurrent users on a Hosted Shared Desktop model and 50-100 concurrent users on a Hosted Virtual Desktop model with the same hardware. Seems like a no brainer, go with Hosted Shared Desktop.

Unfortunately, it isn’t an either/or answer. It is more of a 70% one way, 20% another way, and 10% a third way.

To do it right, you have to start by understanding your users. Citrix calls it User Segmentation Analysis, but it essentially means gathering information about my user groups to understand what they need to do their job. If you do this, you will see that the decision isn’t nearly as difficult as you expect. Here are a few examples and how I would align the groups with the most appropriate virtual desktop model (and I’m mostly looking at the application aspect, but we would also want to look at user location, mobility and end points):

Group Description Recommendation
Group 1 Users are mostly within one or two applications all day. This application is the main line of business application. Their performance is based on speed and accuracy. Hosted Shared Desktop
Group 2 Users have a core set of applications they require to do their jobs. Oftentimes, these users must be able to modify system-level settings like environment variables, or install their own applications Hosted Virtual Desktop (Dedicated)
Group 3 Users focus on content creation utilizing Microsoft Office and Adobe Photoshop. They users also browse for content and graphics online via a browser. Hosted Shared Desktop
Group 4 Users utilize a few applications that consume significant amounts of CPU resources when doing certain activities (video rendering or code compiling) Hosted Virtual Desktop (Streamed to Blade)
Group 5 Users require admin-level priviledges for certain applications Hosted Virtual Desktop (Pooled)

I prefer to start with the most scalable solution first, as long as it meets the user requirements. That is the key point… user requirements. Many users need additional functionality or capabilities that are not suitable for the hosted shared desktop model. Once you reach these users, you need to figure out how to provide them with the most appropriate desktop.

In the end, there is a balancing act that goes into the design. If I have a small group of users that can utilize 3 different models, and 1 of the models is already in place, then it only makes sense to have those users use that model. It simplifies the infrastructure and makes it easier to manage.

Daniel – Lead Architect – Worldwide Consulting Solutions
Twitter: @djfeller
XenDesktop Design Handbook
Blog: Virtualize My Desktop
Facebook: Ask the Architect
Email Questions: Ask The Architect

It’s been almost 4 months since I mentioned in my last blog to “stay tuned” for the Cisco Validated Design guide (CVD) for Cisco UCS with XenDesktop on Hyper-V and trust me, we have been busy testing at the Cisco labs since then. Well, I am glad to share with you that the CVD is now released and available here.  The report provides XenDesktop validation results and configuration details on Hyper-V for the Cisco UCS B250-M2 blades with 192GB RAM.  

As part of our testing, we successfully achieved linear scalability of one to sixteen blades by placing 110 Windows 7 virtual desktops with 1.5GB RAM on a single UCS blade, then 880 desktops on 8 UCS blades, and finally 1760 desktops on 16 UCS B250-M2 blades while keeping the user response time the same and very acceptable. The density numbers are really impressive obviously due to the large amount of memory in the blades.

To review all three CVDs (XenServer, Hyper-V and vSphere), please refer to the Cisco Validated Design Guides here.

Bhumik Patel

Principal Consultant, WW Consulting Solutions

Twitter: @bhumikp

At Citrix Synergy Berlin you will have the opportunity to learn specifics about how to setup your multi-forest domain with Citrix Provisioning Services 5.6 where you have the Provisioning Services infrastructure and target devices in separate forests. Learning labs will guide you through this topic and also other new features of Citrix Provisioning Services 5.6 such as vDisks updates with read-only stores. You will fall in love with its key features and to see how easy is to implement the XenDesktop’s Provisioning Services feature in your enterprise environment. Your initial step is to click on the link below and add SYN404D – Operating System delivery to desktops session to your agenda. This is a 3 hour session about the Citrix Provisioning Services and how to simplify your job.

Register for Synergy 2010 Berlin

Session: SYN404D – Operating System delivery to desktops


October 04, 9:00 am – 12:00 pm
October 05, 9:00 am – 12:00 pm
October 07, 2:00 pm – 5:00 pm
October 08, 1:00 pm – 4:00 pm 
Elisabeth Teixeira
Principal Engineer - Worldwide Technical Readiness
Follow Me on twitter: @lizteixeira

Update
We have delivered the Tech Talk on Essentials for using Windows PowerShell with XenApp and XenDesktop and both the recording and presentation are now available for viewing. We also have a separate blog for the Q&A from the session.

Session Description
Learn how to simplify your XenApp and XenDesktop administration using simple but effective PowerShell scripts. This session will provide a high-level overview of the PowerShell SDK for XenDesktop 4 and XenApp 6, and will focus primarily on live demos of PowerShell scripts for automating various aspects of these environments.

Programming knowledge is not required – an administrator with a basic scripting background can leverage the knowledge gained in this session and put it to use within their own environment. We hope to see you there!

Reference Materials
Mike and I have started to put together a blog series on the XenDesktop and XenApp PowerShell SDKs to be used as reference materials for the Tech Talk. If you haven’t already seen them, feel free to check out the links below. We will be giving live demos of several of the scripts mentioned as part of these blogs.

XenDesktop 4 PowerShell SDK blog series – by Ed York

XenApp 6 PowerShell SDK blog series – by Mike Bogobowicz

About the Presenters
Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site: http://community.citrix.com/p/product-automation#home
Follow Ed on twitter: http://twitter.com/citrixedy

Mike Bogobowicz – Principal Consultant – Worldwide Consulting Solutions
Blog Site: http://community.citrix.com/blogs/citrite/michaelbog
Follow Mike on twitter: http://twitter.com/mcbogo

Thank you to all those that attended the Essentials for using Windows PowerShell with XenApp and XenDesktop Tech Talk on August 24, 2010 – we had a fantastic turnout! For those of you that missed it, both the recording and presentation have been posted.

Mike Bogobowicz and I co-presented this session where I led the XenDesktop PowerShell SDK side, and Mike let the XenApp PowerShell SDK side. This blog will focus on just the XenDesktop SDK questions that came from the session. Mike will have a separate blog post on the XenApp SDK questions.

XenDesktop SDK Q&A
Here’s the list of questions we received specific to the XenDesktop PowerShell SDK. In no particular order:

Q: Are you going to post the scripts you used in today’s session?
A: All the scripts we demonstrated are contained in the blog series that was posted prior to the session. You can find links to the blog series at the bottom of this article.

Q: What does “DDC” mean?
A: First, this is a great question!! If you are a XenApp admin that hasn’t touched XenDesktop, DDC is a brand new term. DDC stands for Desktop Delivery Controller. It is the component of XenDesktop 4 that brokers virtual desktops to end-users, much like how the XenApp Zone Data Collector (ZDC) brokers published applications to end-users.

Q: This looks a lot like the PowerShell SDK for XenServer, just different commands. Is it similiar?
A: Yes, I believe Engineering made the PowerShell SDKs for XenServer, XenDesktop, and XenApp similar in structure on purpose. In that way, once you learn one, learning the others will be much simpler.

Q: The 4th XenDesktop PowerShell script from the Tech Talk showed how to shut down a single virtual desktop session. How would you modify this script to interact with an entire Desktop Group or multiple users?
A: The key here is to play with the parameters of the Get-XdSession cmdlet. If you provide the -User parameter, you can get specific user sessions. If you provide the -Group parameter, you can get all sessions from a particular desktop group. If you don’t include either of these parameters, you’ll get back all sessions across the entire farm. To get started, I would encourage you to check out the full help details for this cmdlet.

Get-Help Get-XdSession -Full

Q: With the virtual desktop session shutdown script, is there a way to allow the user to prevent the shutdown?
A: I don’t believe so. Once you call the Stop-XdSession cmdlet to shut down the session, it’s going to perform an immediate shutdown of that virtual desktop. That’s why in the demo I mentioned sending a warning message to the user to give them a heads up of the shut down, perhaps 10 to 30 minutes prior for them to save their work.

Q: Do we need to provide some credential (i.e. username/password) in order to be able to run the PowerShell script from a remote domain machine?
A: You can execute all of the scripts I’m providing in the blog series from a remote domain machine. I did some additional research on this and it looks like your logged on account to that remote machine needs to be both a XenDesktop admin and have access to the XenDesktop database. This would make sense from a security perspective to not allow any domain user to manipulate your farm. So the security is performed with your logged on machine account. We don’t need to pass a XenDesktop credential to the XenDesktop cmdlets.

Q: Can you create a desktop group in a specific folder?
A: I checked the New-XdDesktopGroup cmdlet that is used for creating a new desktop group and I couldn’t find a parameter for specifying a folder as part of the desktop group creation process. It does appear, however, we can move a desktop group to a new folder immediately after it’s been created. You would use commands like below:

#************************************************************
#Move desktop group to a different folder
#************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopGroupName = "Windows XP"
$strTargetFolderName = "Folder1"

#Get the target XenDesktop folder 
$xdfolder = Get-XdFolder -Name $strTargetFolderName -AdminAddress $strDDCAddress 

#Get a particular desktop group 
$xdgroup = Get-XdDesktopGroup -Name $strDesktopGroupName -AdminAddress $strDDCAddress -HostingDetails

#Display the current folder assignment for the desktop group
echo $xdgroup.Folder 

#Change the folder assignment for the desktop group
$xdgroup.Folder = $xdfolder

#Apply the change to the DDC
Set-XdDesktopGroup $xdgroup

#Verify the update 
echo $xdgroup.Folder

Q. Is it possible to enable the “User-driven desktop restart” setting for a desktop group as part of creating the desktop group with PowerShell?
A. Just as with the last question, I checked the New-XdDesktopGroup cmdlet for creating a new desktop group and couldn’t find a way to enable this setting as part of executing that command. However, you can enable this setting immediately after creating the new desktop group. You would use commands like below:

#*************************************************************************************
#Enable "User-driven desktop restart" setting for a desktop group
#*************************************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopGroupName = "Windows XP"

#Get a particular desktop group 
$xdgroup = Get-XdDesktopGroup -Name $strDesktopGroupName -AdminAddress $strDDCAddress -HostingDetails

#Enable user-drive desktop restart
$xdgroup.AllowUserDesktopRestart = $true

#Apply the change to the DDC
Set-XdDesktopGroup $xdgroup

#Verify the update 
echo $xdgroup.AllowUserDesktopRestart

Q: If you have multiple DDCs, do you have to specify each, or just the master DDC to run against?
A: In a multiple DDC environment, if you point your scripts to the “master” DDC you should be fine. My XenDesktop farm only has one DDC so I can’t verify this one, but I’m thinking you might be able to point the scripts to any of the DDCs in the farm. If someone has a larger farm out there that can verify for us, please post a note at the bottom. Essentially, check out the scripts from the blog series and look for the -AdminAddress parameter I’ve been using for several of the XenDesktop cmdlets. If you have multiple DDCs, experiment putting the different IP addresses for that parameter and see if the script runs fine against each DDC in the farm.

Q: How can you check for disconnected sessions? Can you tell how long they’ve been disconnected?
A: The code snippet below explains how to get all the disconnected sessions for the XenDesktop farm. It looks like the properties of the $xdsession object will tell you the start time of the session, but not when it was disconnected.

#*****************************************************************
#Checking for disconnected virtual desktop sessions 
#*****************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"

#Get all disconnected sessions for the XenDesktop farm
$xdsession = Get-XdSession -AdminAddress $strDDCAddress -SessionDetails | where { $_.State -eq "Disconnected" }

#Display the disconnected sessions
echo $xdsession

Q: Can you monitor what is happening on the virtual desktop through PowerShell?? Or interact with a specific session (SendKeys style)?
A: The XenDesktop SDK doesn’t provide much in way of getting the details inside the session. In the Tech Talk, I demo’d how you can send messages to the session. You can also get some attributes for the session such as the client name and client IP that launched it. This blog goes into some of that. You can probably run other types of PowerShell scripts from within the virtual desktop session to get some additional metrics or details. Plus, there’s Citrix EdgeSight as well to have an agent running on the virtual desktop to collect performance metrics and other details!

Q: When doing an automated desktop deployment using MDT or other image deployment tool, what is the best way to have the desktop imported into it’s appropriate Desktop Group as part of the post install task sequence? These desktops are not pre-staged in AD and would prefer not to have the SDK installed on each VM. Can it execute a script on a remote server to do the import?
A: The XenDesktop PowerShell scripts do not need to be executed on the virtual desktops nor the DDC for that matter. They can be executed from any domain machine that can reach the DDC. You can use this blog for a sample script on adding virtual desktops to a desktop group. As part of your MDT automation process, you are going to want to install the virtual desktop agent (VDA) software on the virtual desktops prior to adding them to the desktop group. You’ll also want these machines added to your domain prior as well.

Q: Is it possible to create an advanced presentation for those comfortable with PowerShell and SDKs?
A: This is something that we’ve been discussing for a bit. Now that we have laid out the groundwork for the XenDesktop 4 SDK Primer, we can now think about adding in some more complex scripts to build on top of that knowledge. If you are experienced with the XenDesktop SDK and have some suggestions for what you would like to see, please post a comment below. For the more complex stuff, it’s always good to have a goal in mind for something practical that is needed out in the field.

Q: Do you cover VMware as a hypervisor in your blogs?
A: I didn’t cover VMware specifically, but the scripts I provided in the Tech Talk and blogs should also work with a VMware ESX host. If you are using VMware ESX to host virtual desktops, you are still considered to be using a VM-based desktop group. In the blogs I created, they were focused on interacting with VM-based desktop groups with XenServer as the host. My understanding is that the syntax should be very close if not identical. If anyone has used the XenDesktop PowerShell SDK for a VMware host, feel free to provide a comment at the bottom regarding your experience. Were the commands pretty much the same? Did you find any differences with using the SDK compared to my scripts with a XenServer host?

Tech Talk Resources
As a reminder, we based the Tech Talk on the blog series we posted prior to the session. You can find all the sample scripts we demonstrated in the Tech Talk within these blogs.

XenDesktop 4 PowerShell SDK Primer blog series – by Ed York

XenApp 6 PowerShell SDK blog series – by Mike Bogobowicz

About the Presenters
Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site: http://community.citrix.com/p/product-automation#home
Follow Ed on twitter: http://twitter.com/citrixedy

Mike Bogobowicz – Principal Consultant – Worldwide Consulting Solutions
Blog Site: http://community.citrix.com/blogs/citrite/michaelbog
Follow Mike on twitter: http://twitter.com/mcbogo

Have you thought about charging your “customers” for IT services you are providing? I bet you have and I thought about that model for quite some time.
The promise of cloud computing, virtualization, usage metering, and IT as a Service often spawn the thoughts of billing the end customer, i.e. business units in a corporation. This is a world where super flexible infrastructure can flip the switch on applications, server workloads, entire desktops and user accounts in a heart beat.
Niel Nicholaisen writes about the topic in this article?
Let me add a few of my own thoughts:
• IT departments can count on (or hope for) a small percentage of a company’s annual revenues as a budget for capex and opex. IT is asked to provide literally the entire workspace and infrastructure for all users and often has to do more with less compared to the previous year. In the healthcare industry, that number stands at roughly 3% of revenues in the US and only about 2% in Europe.
• IT departments often get frustrated, because they have to provide expensive and complicated applications to a handful of users that chew up a large portion of resources and expenditures to do so.
• With the dawn of desktop and broader application virtualization, IT departments are tempted to charge for their services on a per user or per application basis. $30 per month for a desktop, $20 per month for Internet access, $5 per month for anti virus, etc.
• The model is obviously tempting for two reasons: It discourages the use of complex and expensive applications and brings the true cost of computing back to the business and it also holds the promise of increasing the IT budget linearly with the services that are provided.

However, as Niel points out, this can alienate the users. First of all, as a user I may find that I get really shoddy service for the $70 per month or so for basic services per user. As a business, I don’t have the choice to go get my Internet access or email service from someplace else . Sometimes (as a business) I think I can, and I may go to a cloud-based email service or attempt to buy my own backup service, but all of that comes at the cost of increasing complexity and introducing expensive integration points.
Keep in mind that IT is just another corporate service. I am not getting charged for payroll processing, legal support, marketing support, etc. Larger companies tend to cross charge for internal consulting services and sometimes for recruiting activities, but that’s pretty much it.

So, here is my recommendation for IT: Go ahead and charge your business units. Be aware of the pushback this may generate. In order to prevent backlash, do the following:
• Be the best in the industry. That’s right. Users will be tempted to compare the service you are providing (at the price you are charging) to consumer-grade services that are available online and that are provided by much larger organizations with better economies of scale. The expectation for the quality of your service goes up as you start charging for it.
• Virtualize applications and desktops. This will not only centralize the data, but make cost more transparent and predictable. If you do this right, you can reduce costs. If you don’t, you can end up driving up your costs, so choose wisely.
• Consider using third party, cloud based services for certain types of apps. Just because you managed something in-house in the past, doesn’t mean that this is the best modality going forward. CRM and web hosting services are examples of apps that have been pushed (or elevated) to the cloud for a while now in the industry.
• Monitor your resource use and utilization to get a grip on the human cost of environment support. The smaller your organization, the more difficult this is going to be. After all, you can’t hire a fraction of a SQL Administrator.
• Ensure that you explain (via your executives) that you have much higher data availability and reliability standards to meet than any publicly available service and that the company is required to provide the services internally to maintain control and ensure compliance.
• Consider implementing a “Bring Your Own Computer” model. We’ve had it at my employer for a while and it’s great. I own the endpoint, and I can manage my computer just fine, thank you very much. I can now have my own desktop, anti-virus, and other consumer grade services to dabble around and get a corporate Windows 7 image (a virtual desktop) from IT with the key apps I need to do my work.
• Expect to get charged by your accountants for the support they may need to lend to you as part of this process

Questions? Comments? Let me know what you think and how you have been managing the cost of providing IT services.

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

The last task that we’ll discuss in this blog series is how to automate the restarting (rebooting) of virtual desktops within XenDesktop. I’ve provided two different scripts in this article – one for restarting a single virtual desktop, the second for restarting multiple virtual desktops at the same time. As you’ll find in the scripts, they look almost identical, making this one of the more easier actions to perform.

This is the 9th and final blog in a series on how to use the XenDesktop 4 PowerShell SDK. In the first blog, I provided info on how to set up your XenDesktop PowerShell environment so that you could run these scripts. If you haven’t done that yet, please visit that article first. In the last blog, I discussed how you can disconnect and stop virtual desktop sessions using PowerShell. For a complete list of topics that I have covered in this blog series, see the bottom of this article.

PowerShell script for restarting a single virtual desktop
The sample script below demonstrates how to restart a single virtual desktop in the XenDesktop farm. Please note the two options provided here for retrieving a reference to the virtual desktop.

#************************************************************
#Restart a single virtual desktop 
#************************************************************

#Add the XenDesktop snap-in to the current PowerShell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopADName = "xpvda1"            #Active Directory machine name
$strDesktopVMName = "WINXP_XD4_VDA1"    #Virtual Machine name

#Option 1 - retrieve a particular virtual desktop by Active Directory machine name
$desktop = Get-XdVirtualDesktop -AdminAddress $strDDCAddress -HostingDetails | where { $_.Name -match $strDesktopADName }

#Option 2 - retrieve a particular virtual desktop by Virtual Machine name
$desktop = Get-XdVirtualDesktop -AdminAddress $strDDCAddress -HostingDetails | where { $_.HostingName -match $strDesktopVMName }

#Restart the virtual desktop 
Restart-XdVirtualDesktop -force -desktop $desktop

PowerShell script for restarting all virtual desktops from a desktop group
The sample script below demonstrates how to restart all virtual desktops for a desktop group at the same time.

#************************************************************
#Restart all virtual desktops in a desktop group
#************************************************************

#Add the XenDesktop snap-in to the current PowerShell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopGroupName = "Windows XP"

#Retrieve all virtual desktops within a desktop group
$desktops = Get-XdVirtualDesktop -AdminAddress $strDDCAddress -Group $strDesktopGroupName -HostingDetails 

#Restart all virtual desktops within the group that are currently powered on
Restart-XdVirtualDesktop -force -desktop $desktops

Analyzing the PowerShell Scripts
Both scripts above are almost identical so we’ll discuss them at the same time. The Get-XdVirtualDesktop cmdlet is used to get a reference to one or more virtual desktops. If you view the help on this cmdlet, you’ll find that it provides various switches (-Registered, -Unregistered, -Group) for performing filtering on the virtual desktops that are returned.

In the first script above, I provided two different ways for getting a reference to a single virtual desktop. The first approach looks for the virtual desktop based on the Active Directory machine name. The second approach looks for the virtual desktop based on the Virtual Machine name. You don’t need both of those statements in the script – I just provided both as it could help understand the cmdlet statement better. Feel free to experiment with them to find which works best for you.

The Get-XdVirtualDesktop cmdlet returns a XdVirtualDesktop object (or an array of them if there is more than one returned). You pass this object as a parameter to the Restart-XdVirtualDesktop cmdlet and that’s it! All the specified virtual desktops will be restarted (if they were already running).

Wrap-up
The blog series is now done! If you found the info within this series valuable or if would like to see some particular things on the XenDesktop PowerShell SDK in the future, feel free leave a comment. Be sure to also sign up for the TechTalk we are delivering on Tuesday, August 24 where you can see several of these PowerShell scripts in action!

Upcoming TechTalk
I will be leading a TechTalk with Mike Bogobowicz on Essentials for using Windows PowerShell with XenApp and XenDesktop on Tuesday, August 24 from 2pm to 3pm EST. If you interesting in learning more about these SDKs first hand and want to see the demos in action, you can sign up here. Feel free to also check out Mike’s blog on XenApp 6 PowerShell scripting here. We hope to see you at the TechTalk!

Blogs in this series

Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site: http://community.citrix.com/p/product-automation#home
Follow Me on twitter: http://twitter.com/citrixedy

As part of my involvement with the Ask the Architect program, I try to venture out into our various Citrix SDKs from time to time to gain an understanding on what we are capable of automating. The XenDesktop 4 PowerShell SDK is something I’ve had on my list for some time to tackle. After all, XenDesktop is a huge focus of the company, PowerShell is the new de facto standard for scripting languages, and the blending of them together can have a huge impact on simplifying administration in a big way.

When I first started to learn the XenDesktop SDK, I didn’t realize that there was actually quite a bit already written about the topic. Many of you may have seen Christian Gehring’s blog on the XenDekstop 2.1 PowerShell SDK. He provides a great summary and some sample scripts for getting started. Paul Wilson also has some recent blogs on creating PowerShell scripts for a Hyper-V/XenDesktop environment.

So why the need for a new blog series? I think there is still quite a bit we can discuss and explore with the XenDesktop SDK. How many of you are XenDesktop admins that have a need for automating various configurations within the environment but you don’t have a background in PowerShell to get started? Or how many of you have seen some sample scripts, but are not quite sure how to customize them to fit your own needs? I’m going to take a different approach with this blog series to not restate what has already been stated, but to provide topics that can benefit those both new to PowerShell and those that already have had some experience with the XenDesktop SDK. In particular, the goals I have for this blog series are as follows:

  • Demonstrate XenDesktop PowerShell scripts that can be executed on both the Desktop Delivery Controller (DDC) as well as any other domain member machine
  • Provide additional insights on what the scripts are doing so that any XenDesktop admin can learn how to create their own scripts or modify the supplied scripts to suit their own environments
  • Provide reference materials for the upcoming TechTalk that I will be delivering on August 24 on how to use the XenDesktop 4 PowerShell SDK. I will be co-hosting this TechTalk with Mike Bogobowicz and we will cover the essentials on the XenApp and XenDesktop PowerShell SDKs.

PowerShell Overview
In this day and age, most of us have heard about PowerShell. We may not have all used it directly before, but it’s something that we see pop up quite a bit on product installations. Both XenDesktop (all versions) and XenApp 6 use PowerShell as their SDK for automating configurations. Citrix Workflow Studio is heavily dependent on PowerShell for the core of how it executes workflows. Microsoft (who creates PowerShell) provides their own PowerShell commands for most (if not all) of their latest products. PowerShell is also pre-installed with Windows Server 2008 and Windows 7. A separate installer is available for earlier Windows operating systems such as Windows Server 2003 and Windows XP.

Essentially, PowerShell can be thought of as an object-oriented scripting language. Let’s break that statement down really quick.

  • First – it’s a scripting language. Like other scripting languages before it (e.g. VBScript), you can create a custom script file that contains a series of PowerShell commands and the commands are executed from the top to the bottom much like how a book page or movie script is read. The key thing about scripting languages and what differentiates them from the core .NET languages (C#, VB.NET, etc.) is that they are not pre-compiled before they are executed. With a standard Windows program, you compile your source code into a binary file (EXE or DLL) first before you execute it. Compiled code can run faster than a non-compiled program since the instructions have already been translated into code that the OS can understand better. To summarize, PowerShell scripts are executed completely at run time, from the top to the bottom, much like how our older VBScripts run.
  • Second – it’s an objected oriented language. As you will soon see in this blog series, many of the XenDesktop PowerShell commands (called cmdlets) will retrieve a configuration from XenDesktop and return it to you as an object. You can define your own variables to store this object within memory. Once you have the object stored inside a variable, you are free to view the properties of the object or call its methods. You can also use this object as a parameter into another PowerShell cmdlet. Being able to natively use and manipulate objects as part of a PowerShell script really simplifies the complexity and length of the script. This concept will be repeated over and over again in all of the scripts that we discuss in this blog series.

Getting Started with the XenDesktop 4 PowerShell SDK
So we know a little bit more about PowerShell, how do we get started with the XenDesktop 4 PowerShell SDK? The cool thing about this SDK is that you can execute XenDesktop PowerShell scripts from any domain member machine, not just the Desktop Delivery Controller (DDC). As long as your machine resides on the same domain as the DDC and the DDC is reachable, the scripts will run just fine. In fact, all of the scripts that I will share as part of this blog series were built and executed on a generic Windows Server 2003 domain member that had no other XenDesktop components on it other than the PowerShell SDK.

1. Determine which machine you want to run your scripts from. For me, the real choice was to either run on the DDC or run on another domain member machine. I chose a general domain member since I know that any script I produce there will also run on the DDC just fine. FYI – I’m finding that many of the XenDesktop scripts that have already been posted to the web will only run on the DDC in their current form. Just keep that in mind as you review the scripts.

2. Install the prereqs for the SDK (PowerShell 1.0 and the .NET Framework 3.5). The .NET Framework 3.5 can be found on the XenDesktop installation media. Powershell 1.0 can be found as a free download from the web here.

3. Insert the XenDesktop 4 installation media (ISO or CD) and select to install the Desktop Delivery Controller SDK. It’s a very simple install, just click Next through a few dialogs.

4. Launch PowerShell. There’s a couple ways you can open the PowerShell prompt to start writing your own XenDesktop scripts:

  • Open the Desktop Delivery Controller SDK Shell from the Start window. – from the Start Window, if you navigate to All Programs –> Citrix –> Desktop Delivery Controller SDK –> Citrix Desktop Delivery Controller SDK Shell, a special PowerShell window will open that already contains the XenDesktop PowerShell snap-in pre-loaded. You can start using the XenDesktop cmdlets right away within this window.
  • Open a generic PowerShell window and add the XenDesktop PowerShell snap-in manually. – I don’t know exactly why, but this is the route I always choose. Maybe it’s the feeling I have more control over my entire session. With this option, open a generic PowerShell window by navigating to All Programs –> Windows PowerShell 1.0 –> Windows PowerShell. At the PowerShell prompt, type the following command to load the XenDesktop PowerShell snap-in.
Add-PSSnapin "XdCommands"

No matter which of these options you choose, PowerShell needs to be allowed to execute scripts in order for the Add-PSSnapin “XdCommands” command to execute correctly. If you perform either of the above options and see some error messages, it mostly likely means that PowerShell has its execution policy set to Restricted. To get the current PowerShell execution policy, type the following command:

Get-ExecutionPolicy

If the above command returns Restricted, we need to relax the policy to something like RemoteSigned. Type the following command:

Set-ExecutionPolicy "RemoteSigned"

5. View the available XenDesktop cmdlets within PowerShell. At the PowerShell prompt, type the following command:

Get-Command -PSSnapin "XdCommands"

6. View the help on a specific XenDesktop cmdlet. For example, to get the details of the Get-XdFarm cmdlet, type one of the commands below. Notice that you can include an extra switch called -full to provide even more detail about the cmdlet. I would definitely recommend doing that when you start out. The pound symbol # just represents a comment. Statements with a leading # are ignored.

#Provide basic data about the cmdlet
Get-Help Get-XdFarm

#Provide comprehensive data about the cmdlet, including full parameter descriptions and sample scripts
Get-Help Get-XdFarm -Full

In the next blog, we’ll take this to the next level and actually start to use the cmdlets to retrieve back information from the XenDesktop farm. Stay tuned!

Available Resources
I mentioned in the sections above about some existing resources on the XenDesktop PowerShell SDK. Whenever you get started with a new SDK, it’s always good to know what is already out there for you to leverage. If I missed any resources, feel free to post a comment and I’ll be sure to update my list…

Upcoming TechTalk
I will be leading a TechTalk with Mike Bogobowicz on Essentials for using Windows PowerShell with XenApp and XenDesktop on Tuesday, August 24 from 2pm to 3pm EST. If you interesting in learning more about these SDKs first hand and want to see the demos in action, you can sign up here. We hope to see you there!

Blogs in this series
I have a lot of blogs planned for this series, and my hope is to complete all of them prior to the TechTalk. Stay tuned for more blogs in this series coming very soon!

Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site: http://community.citrix.com/p/product-automation#home
Follow Me on twitter: http://twitter.com/citrixedy

In another blog, I discussed Windows 7 services that you might wish to disable when going down the path of desktop virtualization. In this article, I’m now focusing on registry modification you will want to make to optimize Windows 7 for virtual desktops. I’ve broken it down into Recommended configurations, Standard Mode configurations (for Provisioning services), and Optional configurations.

As I learn more from upcoming Windows 7 implementations, I’ll be updating the following tables, so it might be worthwhile to stay updated with RSS or subscribe via Email. Now, for the good stuff…

Recommended Configurations

The following registry changes are recommended for all deployment scenarios and would almost always be desirable in a Windows 7 hosted VM-based VDI desktop implementation:

Configuration Optimizer Registry Modification (in REG format)
Disable Last Access Timestamp Yes [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] “NtfsDisableLastAccessUpdate”=dword:00000001
Disable Large Send Offload No [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters]
“EnableOffload”=dword:00000000
Disable TCP/IP Offload No [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“DisableTaskOffload”=dword:00000001
Increase Service Startup Timeout No [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control] “ServicesPipeTimeout”=dword:0002bf20
Hide Hard Error Messages No [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows] “ErrorMode”=dword:00000002
Disable CIFS Change Notifications No [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer]
“NoRemoteRecursiveEvents”=dword:00000001
Disable Logon Screensaver No [HKEY_USERS\.DEFAULT\Control Panel\Desktop]
“ScreenSaveActive”=”0″

Note: The Optimizer column indicates whether this registry change is included in the XenConvert Optimizer tool that is installed with the Provisioning Services target device software.

Standard Mode Recommended Configurations

The next set of registry changes are recommended for images deployed using standard mode vDisk images with Citrix Provisioning services. Standard mode images are unique in that they are restored to the original state at each reboot, deleting any newly written or modified data. In this scenario, certain processes are no longer efficient. These configurations may also apply when deploying persistent images and in many cases should be implemented in addition to the changes recommended in the preceding section.

Configuration Optimizer Registry Modification (in REG format)
Disable Clear Page File at Shutdown Yes HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]

“ClearPageFileAtShutdown”=dword:00000000
Disable Offline Files Yes [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\NetCache]
“Enabled”=dword:00000000
Disable Background Defragmentation Yes [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction] “Enable”=”N”
Disable Background Layout Service Yes [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OptimalLayout]
“EnableAutoLayout”=dword:00000000
Disable Bug Check Memory Dump Yes [HKLM\SYSTEM\CurrentControlSet\Control\CrashControl]
“CrashDumpEnabled”=dword:00000000
“LogEvent”=dword:00000000″
SendAlert”=dword:00000000
Disable System Restore Yes [Software\Policies\Microsoft\Windows NT\SystemRestore] “DisableSR”=dword:00000001
Disable Hibernation Yes [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power] “Heuristics”=hex:05,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,3f,42,0f,00
Disable Memory Dumps Yes [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl] “CrashDumpEnabled”=dword:00000000 “LogEvent”=dword:00000000 “SendAlert”=dword:00000000
Disable Mach. Acct. Password Changes Yes [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
“DisablePasswordChange”=dword:00000001
Redirect Event Logs No Set appropriate path based on environment.HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application]
“File”=”D:\EventLogs\Application.evtx”


[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security]
“File”=”D:\EventLogs\Security.evtx”


[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\System]
“File”=”D:\EventLogs\System.evtx”
Reduce Event Log Size to 64K Yes HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application]
“MaxSize”=dword:00010000
[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security]
“MaxSize”=dword:00010000


[HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\System]
“MaxSize”=dword:00010000

Optional Configurations

This last set of machine-based registry changes is optional regardless of whether the image is deployed as a persistent or standard image. In many cases, the following configurations should be implemented; however, these configurations should be analyzed for suitability to each unique environment.

Configuration Justification Registry Modification (in REG format)
Disable Move to Recycle Bin Although the recycle bin will be deleted on subsequent reboots, disabling this service altogether might pose a risk in that users will not be able to recover files during their session. Although this setting is part of the optimizer, it might be advantageous to not disable the Recycle Bin. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\BitBucket]
“UseGlobalSettings”=dword:00000001
“NukeOnDelete”=dword:00000001

Note: These are only recommendations. You should implement these at your own risk

Remember, you can stay current with this and other Windows 7 virtual desktop recommendations via the Virtualize My Desktop – Windows 7 site.

Daniel
Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect