08.04.10
Posted in VDI at 3:40 am by Administrator
In a bit of a departure from my normal Group Policy banter, I wanted to talk a little bit about VDI, or Virtual Desktop Infrastructure. Like most things around virtualization, there’s a ton of hype about the promise of virtualizing desktops. Companies are starting to deploy VDI in real production environments. Its by no means the majority of new desktop deployments, but as with any new technology, there are early adopters that are dipping a toe in to discover how it may (or may not) help.
That said, my friends Don Jones and Greg Shields recently posted an article on TechTarget entitled, “Four reasons why VDI might not be right for you” in which they state right up front, “We’ll just say it: Virtual desktop infrastructure is a bad idea.”
Well, that statement is eye-catching but in my experience it is not the whole story. So I thought it would be a useful exercise to review their 4 points and see where there is agreement and disagreement.
1. Their first point is that “You might not save any time or money” and go on to say that , “ If you end up having one virtual desktop per user, then you have achieved nothing other than relocating those users’ computers from their desks into the data center”
My own experience is generally different here. First off, deploying VDI is not always about saving money, as strange as that seems. Sometimes it is about security–moving certain user population’s desktops to the Data Center solves some otherwise thorny data loss prevention problems that are critical to many organizations. Throw in the fact that software distribution and patching stays within the data center and is far more likely to have higher success rates, and its easier to make the case based on that centralization alone. The comment about ending up with one virtual desktop for each user is important, but misses the larger point about VDI. Let’s look at where desktop management costs come from first. Primarily you have your capital costs (hardware and software) and then you have your operational costs (people costs to maintain systems). Most would agree that the operational costs of the typical desktop far eclipses the capital costs, but those operational costs are often hard to quantify, so people often fall back to comparing capital costs. Ok. So is VDI always more capital intensive than physical desktops? Actually, not always, even in the scenario where you have 1 virtual desktop for every user, depending upon the workload, density of virtualization on your hypervisor, etc. I have seen examples where the costs are roughly the same between VDI and physical hardware. However, I do want to acknowledge a key point that Don and Greg make here. If the “access device” you are using to access your VDI instance is just another PC running Windows, then it becomes harder to make the case that patching and updating your access device and patching the VM is ever going to be cheaper. This makes a stronger case for considering thin terminals or technology like WinFLP (it has a new name now that eludes me at the moment) as the preferred access device for VDI.
2. They state that, “Virtual desktops can cost more than real ones“.
This is a continuation of #1 above and indeed there is the risk of this, depending upon how VDI is deployed. I think the first incorrect assumption here is that most enterprises are paying 400-500 for desktop hardware. While you and I might pay that for a stripped down PC for the home, few enterprises buy such machines. More realistically, enterprise PCs can typically cost anywhere from 600-1000 dollars or more, depending upon the bells and whistles. At the higher end of that range, VDI gets very close, especially when using blade servers with integrated storage and networking and again, depending upon the densities you achieve (i.e. # of VMs per physical server).
They go on to talk about the so-called “false costs” of managing desktops, “You can ignore them in the calculation above because they don’t go away with the move to VDI”. However that is only the case if you deploy one persistent desktop to each user, which is arguably the “training wheels of VDI”. They hint at this by talking about pooling, but pooling is only half the story. The real benefits of VDI come in when you deploy technology that lets you share a base image across multiple users (e.g. Linked Clones from VMWare or the OS Streaming technology in Citrix XenDesktop). This is where the costs really start to make sense because not only do you start saving big time on storage (admittedly the largest chunk of VDI HW costs) but you also can potentially reduce your management costs (those “false costs”) by only having to patch one desktop image for every 100 or more users.
3. This point talks about storage, where they state that, “VDI converts inexpensive desktop storage to expensive SAN storage”
I would agree with this if SAN Storage were the only option for VDI and if someone wasn’t deploying one of the image sharing options I mentioned in #2. But again, that would not be the best practice. When you also take into account the fact that user data is already typically redirected to file servers, that applications can and should be virtualized and that you no longer have thousands of DAS volumes to try and backup, protect, and prevent information leaks from, the hard and soft costs of storage start to work in VDI’s favor.
4. They wrap up by saying, “VDI’s layers are still too many, too complex”
While I wasn’t able to find the presentation they referred to that detailed 19 different layers to VDI, my experience has not shown that. Aside from the connection broker and client access pieces, many of processes enterprises use today to manage servers and desktops is applicable to VDI. I think one key challenge in VDI is mostly organizational. That is, many enterprise shops have traditionally separated desktop and server into separate groups and disciplines. VDI forces those to come together and sometimes that can create challenges. I would wager that for many shops, overcoming those are as big as the technical challenges.
Overall, despite the fact that I have some disagreements with Don and Greg, I do agree that their overall premise, that VDI is not a slam dunk for many shops, is spot on. It certainly doesn’t make sense yet for most IT shops that aren’t enterprise in size. Even enterprises today are walking before they run, with VDI, and are probably not delivering on the promise of VDI’s potential cost savings. In addition, not every user workload should be considered a VDI candidate. There are some workloads where the costs just don’t make sense, where technologies like Remote Desktop Services or, good old physical PCs make more sense. But longer term, as companies and technologies evolve, I believe that VDI will deliver on its promise, just as server virtualization has, and will be a dominant presentation mechanism over time. Throw in the fact that VDI frees you from having to use a PC as an access device (think iPad or other mobile device) and the possibilities grow exponentially.
Permalink
07.23.10
Posted in General Stuff, Group Policy Preferences, Security-related at 10:24 pm by Administrator
Microsoft recently announced a new security vulnerability in Windows shortcuts that affects all versions of Windows since XP! Its references here: http://support.microsoft.com/kb/2286198. This particular vulnerability takes advantage of the icon that appears in shortcut (.lnk and .pif) files on Windows. Within the article cited above, Microsoft provides a “FixIt” workaround for the problem that essentially removes the icon from the shortcut, leaving a blank icon in its place. In looking at what they are doing in the FixIt, it struck me that you could leverage GP Preferences’ registry extension to blow this fix out to your entire environment pretty quickly. So, what I did was create two new GP Preferences registry items, that update the appropriate registry values, and remove the data from those values. The values in question are:
HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler\@
HKEY_CLASSES_ROOT\piffile\shellex\IconHandler\@
Where @ represents the “Default” registry value. Each of these values needs to have no data in them in order for this fix to work (and you’ll need to restart the target machine).
The GP Preferences items were very easy to craft. The following screenshot shows an example of the one I did for the lnk files:
Note that the value data field is left blank. That, in combination with using the “Update” action on the GP Preferences item, makes it easy to blank out a registry value. I then repeated this same process for the piffile path in the registry. Since I created this policy under “Computer Configuration”, I targeted the GPO to my computer objects in AD by linking it to an OU containing my computers. During the next policy refresh, the fix applied and I was protected. When an update is provided by Microsoft, you can again use GP Preferences registry extension to update the registry value with its previous, default value, which is “{00021401-0000-0000-C000-000000000046}” for both lnkfile and piffile.
Cool! GP Preferences strikes again!
Darren
Permalink
07.22.10
Posted in General Stuff, Microsoft-Related, Security Policy, Security-related at 10:02 pm by Administrator
Some of you may have seen a twitter post I did a while back letting folks know about the Security Compliance Manager, which is a tool from Microsoft that lets you manage, edit, report, search and export security templates and baselines. This tool is pretty cool, but it also has a hidden gem in it. When you install the SCM, you will notice a folder within its program group called “LocalGPO”, which contains a package called localgpo.msi. When you run that MSI it installs some files within a folder on your hard drive, and one of those files is a script called localgpo.wsf. What this script can do is pretty cool. It can do 3 things against your local GPO that I really like:
- It can backup your local GPO to a GPMC formatted backup. Which means you could backup a local GPO and then use GPMC to import it into a domain-based GPO.
- It can take a GPMC backup of GP settings and import them into a local GPO on a machine.
- It can restore a local GPO to its default state.
These are three great features for managing the local GPO. Let’s take a look at how to use each. For backing up the local GPO, the syntax is simple:
From a command shell, I simply type:
cscript LocalGPO.wsf /path:c:\gpbackups /export
Where c:\gpbackups is a path to where I want to store my backup and /export tells the script to export my local GPO settings.
Now if I want to import a GPMC backup into my local GPO, the syntax is even easier. I simply provide the path to the GUID-Named folder that GPMC creates under the backup directory when you back up a GPO, like this:
cscript LocalGPO.wsf /path:C:\gpbackups\{42ADD8FE-EDF6-479B-92C6-557343D8D091}
And, to restore a local GPO to its default config:
cscript LocalGPO.wsf /restore
Pretty easy to use and this script seems to support every OS from XP to Win7. A couple of caveats however. In looking at the script, Microsoft is only supporting Administrative Templates and Security Policy within these backup and restore operations (understandable given the ship vehicle for this thing). So if you have other policies like Scripts or IE Maintenance within your local GPO, it won’t be captured. Also, the script does not appear to deal with the multiple local GPOs feature supported in Win Vista and above. So if you have per-user local GPOs, they are not captured–only the default local GPO.
That being said the script does provide some good basic functionality as well as a good instructional document on how to capture and reset security settings from the local GPO (which are essentially stored in the local SAM rather than on the file system as in domain-based GPOs).
Hope this proves useful to you!
Darren
Permalink
07.19.10
Posted in Cool New Products at 4:43 am by Administrator
This last week, we (SDM Software) released a new version of GPO Compare and a brand new product in GPO Exporter. Why are these significant? Well, first off, GPO Compare now provides full support for all GP settings that were included in Win7 and Server 2008-R2, including GP Preferences. It also includes the ability to compare live GPOs to GPO backups (or any combination therein). And, it provides the ability to view those differences either in a tree view that looks much like GPO Editor, or in a grid view. You can also search for settings within the difference reports by keyword. Perhaps as exciting for you scripting junkies, both GPO Compare and GPO Exporter provides PowerShell cmdlets that let you perform comparisons or GPO exports from the command-line. Cool! So, what is GPO Exporter? Well, as the name implies, its a tool for letting you export settings from your GPOs. Think of it as part documentation/inventory tool and part real-time GP search tool. You can use the Exporter to dump all of the settings across all of your GPOs into a big list. Then you can search and sort that list to discover interesting things like redundant settings across GPOs, particular settings that you might be looking for but aren’t sure which GPO they reside in, etc. The Exporter also lets you dump GPO settings that you select to CSV file. This is kinda cool because if you are trying to consolidate your GPOs down to a smaller number, you can essentially pick settings out using GPO Exporter, export them to CSV, and use those as input for new GPO creation by leveraging our Group Policy Automation Engine (GPAE). Double-cool. So, check out these two new/updated products on our website and let me know what you think!
Darren
Permalink
06.22.10
Posted in Group Policy Preferences, Security-related at 10:47 pm by Administrator
Well, I’ve been crazy busy working on some new product releases but I wanted to take a moment to blog about some useful features in GP Preferences that often slip through the cracks. I saw a blog post today about how you could use a custom ADM file to remove administrative shares on Windows systems. This works pretty well, but I always prefer it when Group Policy makes it really easy for me to manage configuration, and GP Preferences does that time and again. With respect to shares, you may want to prevent users from publishing shares on their workstations, or you may just want to get rid of the administrative shares for security reasons. In either case, you’ll find that the Network Shares GPP feature can fill the bill. If you navigate to Computer Configuration\Preferences\Windows Settings\Network Shares, you’ll find this hidden gem. Right-click the Network Shares node to create a new share policy. The key to accessing the share removal feature is to choose the Delete action on the network share policy item you create, as shown below:
Note that within the policy, you can choose to remove all regular shares (i.e. those that the user creates), all hidden, non administrative shares (i.e. shares created by the user using the $ hidden marker) and admin shares (e.g. c$, admin$, etc.)
Obviously, you’ll want to use this feature carefully, especially when removing built-in administrative shares that are often used by remote management tools. But, the ability to remove user shares is especially useful in preventing your users from creating a peer-to-peer file sharing network under your nose, with little or no access controls!
Enjoy!
Darren
Permalink
04.16.10
Posted in Bugs at 3:58 pm by Administrator
Thanks to reader Ryan Steele for bringing my attention to the fact that MS has released a hotfix to resolve the GPMC reporting bug that was introduced when Win7 and Server 2008, R2 shipped. I had documented this bug in an earlier blog post. Ryan let me know that MS finally issued a hotfix for this, described at http://support.microsoft.com/kb/981750.
Darren
Permalink
04.11.10
Posted in WMI at 9:30 pm by Administrator
This entry isn’t strictly related to Group Policy, but something I came across in that context a few days ago. There is a WMI class called Win32_Product. Querying this class lets you enumerate all installed MSI applications on a given system. This might sound useful for, say, a Group Policy WMI filter. You might be tempted to use it to create a conditional Group Policy scenario whereby you only process a policy if a particular application is installed. Here’s why that would be a bad idea. First off, Win32_Product is one of those horribly un-optimized WMI providers. What that means is that it could take many seconds or even many minutes to complete a query such as “Select * from Win32_Product”.In other words, its dog slow. So, putting it in a WMI filter means that GP processing will wait on the completion of that dog slow query before preceding. Not a great thing.
To make matters worse, querying this class has a very annoying side effect that I just learned about, and that is documented in this KB article (http://support.microsoft.com/kb/974524). Here’s the issue. When you query this class, the way the provider works is that it actually performs a Windows Installer “reconfiguration” on every MSI package on the system as its performing the query! You can see the effect of this in the application event log with dozens of Windows Installer messages showing each installed application being reconfigured. A reconfiguration includes validating the application’s install, up to and including doing an MSI repair if there is an inconsistency found between the package and the original MSI file. This was particularly irritating in one case where I had set a policy to disable a service that was installed on the system, but whenever a Win32_Product query ran, it would “repair” the application that had originally installed that service, thus re-enabling the service! Not good.
So, the lesson here is, avoid using Win32_Product at all costs–it stinks! Also note that the Item-level targeting filter for MSI packages in Group Policy Preferences DOES NOT use this problematic class, so you’re safe there.
Darren
Permalink
02.24.10
Posted in GPMC at 6:35 pm by Administrator
As a follow-on to my last blog post, here’s another interesting Group Policy Backup scenario to keep in mind. A user emailed that they were having problems importing a GPO backup that was created on a test Server 2008-R2 AD domain, into a Server 2003 AD domain. Theoretically this should work ok, but the user was getting non-descript errors about directory attributes not being found when they tried the import. I scratched my head for a bit on this one and then it hit me! I asked the following question, “Are you using Wired or Wireless Policy within that GPO on the 2008-R2 domain?”. His answer was a resounding “YES”, and then I knew where the problem was.
Microsoft makes decisions about where to store GP settings for each policy area (e.g. registry, security, folder redirection, etc.) based on the amount and type of data they need to store. In some cases, like registry policy, the settings are stored in files in the SYSVOL part of the GPO, called the Group Policy Template, or GPT. In other cases, liked the new Wired and Wireless policies that were first introduced in Server 2008, those settings are stored in the AD part of the GPO, called the Group Policy Container, or GPC. In order to store these settings in AD, Microsoft often introduces new schema classes and attributes to AD to accomodate the setting types. In fact, that is exactly what was happening here.
The user was creating the GPO settings in a version of AD that contained these newer schema extensions, and then tried importing those backed-up GPOs into a version of AD that did not. The result was the failure they saw. All it took to resolve was to update the Server 2003 AD schema to at least the Server 2008 version, and the import worked. There was no need to upgrade their DCs to accomodate the newer settings–all that was needed was the proper schema extensions and all was well (of course, they still need clients that can process those newer settings–in this case Vista and greater).
Problem solved!
Darren
Permalink
02.05.10
Posted in General Stuff at 3:24 pm by Administrator
I had a question recently that I thought was worth blogging. The question was, “if I create a GPO using Windows 7, Server 2008 or similar newer platform”, then backup that GPO using XP or Server 2003, will it back up everything?”. The answer, not surprisingly, is “it depends”. GPMC Backup only backs up the “policy areas” that it knows about. For example, if I set some policy settings within Administrative Templates policy on Server 2008 and then backup that GPO using GPMC running on XP, those Admin. Template settings will be backed up just fine, because the Admin Templates policy area exists on both versions of Windows.
But lets say I create a GPO from GPMC using Windows 7, and set some GP Preferences settings or some of the new “Advanced Audit Configuration” options, then try to backup that GPO from XP or Server 2003′s GPMC. In that case, neither the GP Preferences nor the Audit settings will be backed up because those policy areas do not exist in XP or Server 2003 (from a GPMC perspective–its true that XP and Server 2003 can process GP Preferences settings, but they cannot manage them).
The bottom line is, as always, if you introduce newer versions of Windows into an environment and plan to leverage newer policy areas, its always best to manage GP from those newer versions of GPMC, since GPMC is backwards-compatible but not forwards-compatible!
Darren
Permalink
01.31.10
Posted in General Stuff at 12:54 am by Administrator
Just a quick note to remind folks that for the 5th year in a row my good friend Mark Minasi is hosting the Minasi Conference in Virginia this Spring. For those of you who are used to going to one of those big conferences, this is a much more “intimate” and, in some ways, more valuable type of technical conference. Mark being who he is, you will hear some of the Windows world’s smartest techies at this event. If you have budget for training this year, you should consider this conference. Not only are the topics usually great but its small enough for you to get much more interaction with the speakers than at your typical TechEd show. Check it out!
Darren
Permalink
« Previous entries Next Page » Next Page »
