Edited post-hoc. A tad over the top. No offence intended Elias!
I’ve been enjoying a quiet start to the year – twitter and blog-wise that is. I turned on tweetdeck for a bit, but to be honest, I really can’t decipher @Beaker. Is it gibberish, or a secret code controlling an army of cloud-based “RT: @Beaker” bots? (#envy). (If you’re lost, #fail, and skip the next paragraph too.)
Then, just as I was about to get on with my day-job, I got a mention from @ekhnaser (#gloat)
“New Article: #Citrix, #VMware, #Storage Vendors Invited To talk #emc #hdscorp @harrylabana @simoncrosby @herrod”
OK, I’ll bite, and if you’re looking for a quick response before moving on, this chap is woefully confused.
Let’s take a look. The first thing that strikes me about Elias’s article is that @herrod is highly unlikely to respond to his challenge. Why? Well for starters he uses DVI (Desktop Virtualization Infrastructure) instead of VMware’s term: VDI. Moreover Steve does have a pretty big job on his hands trying to complete Project Redwood.
The weather is far from awful in DVI land, as Elias seems to think. But he is right to point out that it has been bad in the past. His point is that with traditional enterprise storage architectures representing as much as 60% of TCO, Hosted Virtual Desktops just don’t make financial sense. The problem? Well, back in the days when VDI meant something, one would create and store a complete Windows client OS VM per user – their hosted virtual desktop. One would likely use VMFS to “manage” storage, making it impossible for the arrays to understand the structure of the real storage task (virtual disk images). With the storage infrastructure flying blind and unable to assist with placement, caching or read-ahead, performance was terrible, and the only way to solve the problem was to buy more storage, and more expensive SAN networking.
So, all the vendors “ran around hysterically” as Elias says, and started to innovate. There has been a flood of new technology – SSD and RAM based caches, array-based thin clones and snapshots, and lots more to boot. The storage ecosystem has done a fabulous job. We at Citrix have always viewed our role as being one that relies on utilizing as much functionality as possible in the storage infrastructure. We love innovative storage partners. For more than two years XenServer (via StorageLink) has had the ability, for example, to leverage in-array snapshots, thin provisioning and fast-clones. But the demons haunting DV storage have their roots in Moore’s Law. A single modern server can generate more IOPS than any array can satisfy. And technology will continue to favor server IOPS on the road ahead.
So, ultimately the solution lies in a proper decomposition of the DV storage problem into its constituent parts. Properly managed, the user’s desktop is composed of the user’s environment, apps and golden OS, and these can be dynamically composed (using various virtualization technologies) on the fly, to build the user’s desktop. Now, on a server running lots of virtual desktops, why would the hypervisor ever pull the golden image Windows desktop over the network more than once? It wouldn’t – the golden image OS should just be there already, and indeed it ought to be shared across all VMs. Ditto for the apps.
Moreover, when we examined the I/O performance of hosted desktop VMs we found that writes outnumbered reads, by as much as 8:1. The culprit? The Windows Page File. According to Chris Wolf’s analysis, the page file should never leave the server. Instead, it is cached locally either on disk or (better) SSD. Finally, a major cause of write IO latency in the storage subsystem is the nearly random behavior of the disk heads when faced with I/O from a large number of desktops. So we eliminated that, by caching writes locally, and transacting large sequential writes to the storage infrastructure.
This is Intellicache – a feature Elias thinks is cool but irrelevant. Well, he’s wrong. Intellicache reduces HVD IOPS by as much as 98%! What ends up hitting shared storage is .. precisely what you wanted – the user’s differences from the golden image state. He’s right in stating that you can’t use live relo with today’s implementation of Intellicache. Big deal – this is a desktop remember! Moreover, he might want to note that we still manage two platform releases per year.
Elias also thinks that Intellicache is not useful for cloud storage. Dude, have you ever been inside a large cloud? Local storage is all that they use. Intellicache is perfect for “instant on” of any OpenStack based cloud workload. He also says “with all due respect, local disk is dead”. My response: Moore’s Law (and Google, Facebook, and every other massive infrastructure you use daily) says you are utterly, totally, irrationally and profoundly wrong.
Workflow Studio 2.5 was released last week and is currently available for download to our customers on MyCitrix. You can get more information and find a link to the download page at http://www.citrix.com/wfs.
This release includes the following new features:
- Expanded platform support (Windows 7 and Server 2008 R2; SQL 2008; PowerShell 2.0; .NET 4.0)
- New activity libraries for Hyper-V and SQL
- Numerous improvements to existing activity libraries
- Expanded security roles
- Performance improvements
- Enhanced usability for workflow properties
The Evaluation Virtual Appliance has not been updated yet, but I will post an update when it is.
Summer is almost over and that means Synergy Berlin is nearly here! We’re busy making final arrangements for our first pan-European show to be held from October 6-8. In advance of the program, I want to draw your attention to my favourite part of the program – the Citrix Innovation Award.
Every day, companies experience the tangible business benefits of virtualisation, networking and cloud computing. Benefits include savings in operating expenses, enhancing productivity and flexibility, cutting power consumption and reducing carbon emissions, to name a few. But there are also a number of organizations that have embraced the power of virtual computing to think about, and to do, business differently. These include companies like Cocamar in Brazil that have used virtualisation technology to expand their market reach; government agencies like Fairfax County, Virginia, that have used the technology to offer cloud-based computing services to cities and townships within the county; and ND SatCom that expanded its offerings to include a satellite-based solution for business continuity and connectivity. These are but a few examples of business innovation, and I know that there are thousands of stories about organisations around the world that have embraced virtual computing to spearhead change.
The Citrix Innovation Award highlights the stories of enterprises that are using virtualisation, networking and cloud technologies in exciting ways to drive innovation in their businesses. As we did for Synergy San Francisco, we’ve thrown open the doors for Synergy Berlin and invited everyone in the industry – partners, customers and employees – to nominate companies that are using virtualisation, networking and cloud technologies in innovative ways to create a dynamic, agile business environment.
Once again, I’m amazed at the diverse range of businesses that implement these technologies, and use them in new and innovative ways. Dozens of nominations were received from all over the globe; from those nominations twelve companies that best embody the spirit of the Innovation Award were shortlisted.
The winner is chosen by popular vote of peer organisations (that means all of you!) and members of the IT industry and will be announced at Synergy Berlin.
The full list of Innovation Award finalists is:
- Chemtura Corporation
- Codan Trygg-Hansa
- CZ Healthcare Insurance
- Derby Public Schools
- LG CNS
- MATERNA
- Medical University of South Carolina
- O’Neill Europe
- Perfetti Van Melle India
- Telecom Italia
- TeleComputing
- The Co-operative Group
Check out their stories of innovation and vote for your three favourites today.
And don’t forget…you can still register for Synergy Berlin! For more info go to www.citrixsynergy.com.
Security has been blamed as the biggest barrier to cloud adoption. Organizational leaders are walking into IT departments with their brand new iPads and demanding access to the network from these convenient devices. And, the beast known as compliance continues to breathe down our necks.
Whether you’re primarily concerned about the cloud, endpoint protection or data security, one thing is for sure – security is broken. Organizations routinely spend way too much on security measures that mostly serve to frustrate users, while contributing little to the overall security of truly sensitive data. And, legacy security practices such as end-to-end ownership, malware signatures and full physical isolation continue to be challenged by end-user demands, highly evolved attacks and new usage patterns.
All is not doom and gloom though – virtualization presents some innovative ways to respond to these business challenges and transcend security challenges that have plagued computing for decades.
In the CTO Crystal Ball session at Synergy Berlin, I’ll be demonstrating the following security trends and more:
- Situational Security – protective measures that are fine-tuned to specific data needs and context
- BAOC (Bring Any Old Computer) – providing realtime device control to take endpoint security concerns out of the equation
- Flying through the Clouds – architecting true multitenant and mixed-mode data cloud security
Please join me along with Harry Labana, Martin Duursma, and Simon Crosby from the Citrix CTO office as we look into the future at Synergy Berlin!
More info on this demo-filled session and the CTO team’s prognostication can be found at:
http://citrix.g2planet.com/synergyberlin2010/public_session_view.php?agenda_session_id=305
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
- Getting Started
- Retrieving the XenDesktop farm properties
- Creating a new desktop group
- Enabling/disabling a desktop group
- Updating the idle pool settings of a desktop group
- Adding virtual desktops to a desktop group
- Adding AD users and groups to a desktop group
- Disconnecting and stopping virtual desktop sessions
- Restarting virtual desktops and series wrap-up
XenApp 6 PowerShell SDK blog series – by Mike Bogobowicz
- Getting a XenApp Farm Inventory
- Checking XenApp Application Setting Consistency
- Checking Server Availability
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
- Getting Started
- Retrieving the XenDesktop farm properties
- Creating a new desktop group
- Enabling/disabling a desktop group
- Updating the idle pool settings of a desktop group
- Adding virtual desktops to a desktop group
- Adding AD users and groups to a desktop group
- Disconnecting and stopping virtual desktop sessions
- Restarting virtual desktops and series wrap-up
XenApp 6 PowerShell SDK blog series – by Mike Bogobowicz
- Getting a XenApp Farm Inventory
- Checking XenApp Application Setting Consistency
- Checking Server Availability
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
At Synergy San Francisco we held the inaugural Citrix CTO crystal ball session where a number of the CTO Office team presented ideas and demos of future technologies and directions. At Berlin we’ll be doing the same thing and raising the bar again on the demo’s and topics covered. Look forward to seeing Simon Crosby, Harry Labana, Kurt Roemer and I present with some pretty cool demos.
I’ll be covering mobility, and specifically some new directions we are taking that may surprise you. For example Citrix has had a strategy where we have provided a version of Receiver for practically any mobile device and we continue on that path. However in the last three years the explosion of new smartphone platforms has enabled numerous new possibilities as to how we can deliver enterprise content to these new phones. The always on connectivity and decent screen real estate are key drivers.
In the session I’ll demonstrate how an Enterprise developer can write a touch enabled application that is published from a XenApp server, and accessed from a range of devices, both Smartphone and tablets. So if you have a problem with your CIO or CEO demanding support for iPhones, Blackberry, Android, WebOS and other yet to be invented tablets and Smartphones, then this is the session for you.
You can find more information on the CTO Crystal Ball session here
Looking forward to seeing you in Berlin!
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
- Getting Started
- Retrieving the XenDesktop farm properties
- Creating a new desktop group
- Enabling/disabling a desktop group
- Updating the idle pool settings of a desktop group
- Adding virtual desktops to a desktop group
- Adding AD users and groups to a desktop group
- Disconnecting and stopping virtual desktop sessions
- Restarting virtual desktops and series wrap-up (this one)
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…
- XenDesktop PowerShell SDK Download
- XenDesktop PowerShell SDK Support Forum
- XenDesktop 2.1 PowerShell SDK blog – Christian Gehring
- XenDesktop and Hyper-V PowerShell Scripts – Paul Wilson
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!
- Getting Started (this one)
- Retrieving the XenDesktop farm properties
- Creating a new desktop group
- Enabling/disabling a desktop group
- Updating the idle pool settings of a desktop group
- Adding virtual desktops to a desktop group
- Adding AD users and groups to a desktop group
- Disconnecting and stopping virtual desktop sessions
- Restarting virtual desktops and series wrap-up
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



