VDI is one of the most intensive workloads in the datacenter today and by nature uses every major component of the enterprise technology stack: networking, servers, virtualization, storage, load balancing. No stone is left unturned when it comes to enterprise VDI. Physical desktop management can also be an arduous task with large infrastructure requirements of its own. The sheer complexity of VDI drives a lot of interesting and feverish innovation in this space but also drives a general adoption reluctance for some who fear the shift too burdensome for their existing teams and datacenters. The value proposition Unidesk 2.0 brings to the table is a simplification of the virtual desktops themselves, simplified management of the brokers that support them, and comprehensive application management .

The Unidesk solution plugs seamlessly into a new or existing VDI environment and is comprised of the following key components:

• Management virtual appliance
• Master CachePoint
• Secondary CachePoints
• Installation Machine

 

Solution Architecture

At its core, Unidesk is a VDI management solution that does some very interesting things under the covers. Unidesk requires vSphere at the moment but can manage VMware View, Citrix XenDesktop, Dell Quest vWorkspace, or Microsoft RDS. You could even manage each type of environment from a single Unidesk management console if you had the need or proclivity. Unidesk is not a VDI broker in and of itself, so that piece of the puzzle is very much required in the overall architecture. The Unidesk solution works from the concept of layering, which is increasingly becoming a hotter topic as both Citrix and VMware add native layering technologies to their software stacks. I’ll touch on those later. Unidesk works by creating, maintaining, and compositing numerous layers to create VMs that can share common items like base OS and IT applications, while providing the ability to persist user data including user installed applications, if desired. Each layer is stored and maintained as a discrete VMDK and can be assigned to any VM created within the environment. Application or OS layers can be patched independently and refreshed to a user VM. Because of Unidesk’s layering technology, customers needing persistent desktops can take advantage of capacity savings over traditional methods of persistence. A persistent desktop in Unidesk consumes, on average, a similar disk footprint to what a non-persistent desktop would typically consume.

CachePoints (CP) are virtual appliances that are responsible for the heavy lifting in the layering process. Currently there are two distinct types of CachPoints: Master and Secondary. The Master CP is the first to be provisioned during the setup process and maintains the primary copy of all layers in the environment. Master CPs replicate the pertinent layers to Secondary CPs who have the task of actually combining layers to build the individual VMs, a process called Compositing. Due to the role played by each CP type, the Secondary CPs will need to live on the Compute hosts with the VMs they create. Local or Shared Tier 1 solution models can be supported here, but the Secondary CPs will need to be able to the “CachePoint and Layers” volume at a minimum.

The Management Appliance is another virtual machine that comes with the solution to manage the environment and individual components. This appliance provides a web interface used to manage the CPs, layers, images, as well as connections to the various VDI brokers you need to interface with. Using the Unidesk management console you can easily manage an entire VDI environment almost completely ignoring vCenter and the individual broker management GUIs. There are no additional infrastructure requirements for Unidesk specifically outside of what is required for the VDI broker solution itself.

Installation Machines are provided by Unidesk to capture application layers and make them available for assignment to any VM in the solution. This process is very simple and intuitive requiring only that a given application is installed within a regular VM. The management framework is then able to isolate the application and create it as an assignable layer (VMDK). Many of the problems traditionally experienced using other application virtualization methods are overcome here. OS and application layers can be updated independently and distributed to existing desktop VMs.

Here is an exploded and descriptive view of the overall solution architecture summarizing the points above:

Storage Architecture

The Unidesk solution is able to leverage three distinct storage tiers to house the key volumes: Boot Images, CachePoint and Layers, and Archive.

• Boot Images – Contains images having very small footprints and consist of a kernel and pagefile used for booting a VM. These images are stored as VMDKs, like all other layers, and can be easily recreated if need be. This tier does not require high performance disk.
• CachePoint and Layers – This tier stores all OS, application, and personalization layers. Of the three tiers, this one sees the most IO so if you have high performance disk available, use it with this tier.
• Archive – This tier is used for layer backup including personalization. Repairs and restored layers can be pulled from the archive and placed into the CachePoint and Layers volume for re-deployment, if need be. This tier does not require high performance disk.

The Master CP stores layers in the following folder structure, each layer organized and stored as a VMDK.

Installation and Configuration

New in Unidesk 2.x is the ability to execute a completely scripted installation. You’ll need to decide ahead of time what IPs and names you want to use for the Unidesk management components as these are defined during setup. This portion of the install is rather lengthy to it’s best to have things squared away before you begin. Once the environment variables are defined, the setup script takes over and builds the environment according to your design.

Once setup has finished, the Management appliance and Master CP will be ready, so you can log into the mgmt console to take the configuration further. Of the initial key activities to complete will be setting up an Active Directory junction point and connecting Unidesk to your VDI broker. Unidesk should already be talking to your vCenter server at this point.

Your broker mgmt server will need to have the Unidesk Integration Agent installed which you should find in the bundle downloaded with the install. This agent listens on TCP 390 and will connect the Unidesk management server to the broker. Once this agent is installed on the VMware View Connection Server or Citrix Desktop Delivery Controller, you can point the Unidesk management configuration at it. Once synchronized all pool information will be visible from the Unidesk console.

A very neat feature of Unidesk is that you can build many AD junction points from different forests if necessary. These junction points will allow Unidesk to interact with AD and provide the ability to create machine accounts within the domains.

Desktop VM and Application Management

Once Unidesk can talk to your vSphere and VDI environments, you can get started building OS layers which  will serve as your gold images for the desktops you create. A killer feature of the Unidesk solution is that you only need a single gold image per OS type even for numerous VDI brokers. Because the broker agents can be layered and deployed as needed, you can reuse a single image across disparate View and XenDesktop environments, for example. Setting up an OS layer simply points Unidesk at an existing gold image VM in vCenter and makes it consumable for subsequent provisioning. 

Once successfully created, you will see your OS layers available and marked as deployable.

 

Before you can install and deploy applications, you will need to deploy a Unidesk Installation Machine which is done quite simply from the System page. You should create an Installation Machine for each type of desktop OS in your environment.

Once the Installation Machine is ready, creating layers is easy. From the Layers page, simply select “Create Layer,” fill in the details, choose the OS layer you’ll be using along with the Installation machine and any prerequisite layers.

 

To finish the process, you’ll need to log into the Installation Machine, perform the install, then tell the Unidesk management console when you’re finished and the layer will be deployable to any VM.

Desktops can now be created as either persistent of non-persistent. You can deploy to already existing pools or if you need a new persistent pool created, Unidesk will take care of it. Choose the type of OS template to deploy (XP or Win7), select the connected broker to which you want to deploy the desktops, choose an existing pool or create a new one, and select the number of desktops to create.

Next select the CachePoint that will deploy the new desktops along with the network they need to connect to and the desktop type.

Select the OS layer that should be assigned to the new desktops.

Select the application layers you wish to assign to this desktop group. All your layers will be visible here.

Choose the virtual hardware, performance characteristics and backup frequency (Unidesk Archive) of the desktop group you are deploying.

Select an existing or create a new maintenance schedule that defines when layers can be updated within this desktop group.

Deploy the desktops.

Once the creation process is underway, the activity will be reflected under the Desktops page as well as in vCenter tasks. When completed all desktops will be visible and can be managed entirely from the Unidesk console.

Sample Architecture

Below are some possible designs that can be used to deploy Unidesk into a Local or Shared Tier 1 VDI solution model. For Local Tier 1, both the Compute and Management hosts will need access to shared storage, even though VDI sessions will be hosted locally on the Compute hosts. 1Gb PowerConnect or Force10 switches can be used in the Network layer for LAN and iSCSI. The Unidesk boot images should be stored locally on the Compute hosts along with the Secondary CachePoints that will host the sessions on that host. All of the typical VDI management components will still be hosted on the Mgmt layer hosts along with the additional Unidesk management components. Since the Mgmt hosts connect to and run their VMs from shared storage, all of the additional Unidesk volumes should be created on shared storage. Recoverability is achieved primarily in this model through use of the Unidesk Archive function. Any failed Compute host VDI session information can be recreated from the Archive on a surviving host.

Here is a view of the server network and storage architecture with some of the solution components broken out:

For Shared Tier 1 the layout is slightly different. The VDI sessions and “CachePoint and Layers” volumes must live together on Tier 1 storage while all other volumes can live on Tier 2. You could combine the two tiers for smaller deployments, perhaps, but your mileage will vary. Blades are also an option here, of course. All normal vSphere HA options apply here with the Unidesk Archive function bolstering the protection of the environment.

Unidesk vs. the Competition

Both Citrix and VMware have native solutions available for management, application virtualization, and persistence so you will have to decide if Unidesk if worth the price of admission. On the View side, if you buy a Premier license, you get ThinApp for applications, Composer for non-persistent linked clones, and soon the technology from VMware’s recent Wanova acquisition will be available. The native View persistence story isn’t great at the moment, but Wanova Mirage will change that when made available. Mirage will add a few layers to the mix including OS, apps, and persistent data but will not be as granular as the multi-layer Unidesk solution. The Wanova tech notwithstanding, you should be able to buy a cheaper/ lower level View license as with Unidesk you will need neither ThinApp nor Composer. Unidesk’s application layering is superior to ThinApp, with little in the way of applications that cannot be layered, and can provide persistent or non-persistent desktops with almost the same footprint on disk. Add to that the Unidesk single management pane for both applications and desktops, and there is a compelling value to be considered.

On the Citrix side, if you buy an Enterprise license, you get XenApp for application virtualization, Provisioning Services (PVS) and Personal vDisk (PVD) for persistence from the recent RingCube acquisition. With XenDesktop you can leverage Machine Creation Services (MCS) or PVS for either persistent or non-persistent desktops. MCS is deadly simple while PVS is incredibly powerful but an extraordinary pain to set up and configure. XenApp builds on top of Microsoft’s RDS infrastructure and requires additional components of its own such as SQL Server. PVD can be deployed with either catalog type, PVS or MCS, and adds a layer of persistence for user data and user installed applications. While PVD provides only a single layer, that may be more than suitable for any number of customers. The overall Citrix solution is time tested and works well although the underlying infrastructure requirements are numerous and expensive. XenApp offloads application execution from the XenDesktop sessions which will in turn drive greater overall host densities. Adding Unidesk to a Citrix stack again affords a customer to buy in at a lower licensing level, although Citrix is seemingly removing value for augmenting its software stack by including more at lower license levels. For instance, PVD and PVS are available at all licensing levels now. The big upsell now is for the inclusion of XenApp. Unidesk removes the need for MCS, PVS, PVD, and XenApp so you will have to ask yourself if the Unidesk approach is preferred to the Citrix method. The net result will certainly be less overall infrastructure required but net licensing costs may very well be a wash.

** Please be sure to check out the updated version of this article for Server2016: Link **

Resource sharing is at the crux of every virtual environment and is ultimately what makes a shared environment feasible at all. A very common pain point in Remote Desktop Services/ Terminal Services (RDS) environments is the potential for a single user to negatively impact every other user on that RDS host. Server 2008 R2 includes a feature called Dynamic Fair Share Scheduling (DFSS) to balance CPU usage between users. This is a proactive feature so it is enabled by default and levels the CPU playing field at all times depending on how many users are logged in and CPU available. In Server 2012 the fair share features have been expanded to include network and disk as well.
From the Server 2012 RC Whitepaper, the 2012 fair share experience:

• Network Fair Share. Dynamically distributes available bandwidth across sessions based on the number of active sessions to enable equal bandwidth usage.
• Disk Fair Share. Prevents sessions from excessive disk usage by equal distribution of disk I/O among sessions.
• CPU Fair Share. Dynamically distributes processor time across sessions based on the number of active sessions and load on these sessions. This was introduced in Windows Server 2008 R2 and has been improved

Cool! New features are great. Fair sharing has been traditionally an on or off feature, this is where the extent of the configuration ends. From what I can see in the 2012 RC, that doesn’t appear to have changed. Of course if you are running Citrix XenApp, you would want to disable all Windows fair share features and let XA take care of those functions. Fair sharing can be controlled via Group Policy or registry but only the CPU piece is visible in the RC GPOs. 
It is also stored all by itself in the registry under \Quota System.
I do see the additional fair share elements in the registry, however, so the missing GPO elements should appear in the RTS version of the product. Obviously, 1 = on, 0 = off. Looks like there is some registry organization work that still needs to happen.
In an environment where 100% of the users run 100% of the same applications with 100% predictable usage patterns, this model works fine. The trouble begins when you need to support an environment the requires some users or applications to be prioritized over others. There is also nothing there to deal with application memory usage. You could make the argument that this is the point at which these special users should be carved off of the shared session host and given VDI sessions. Luckily, WSRM is available to provide tighter controls in a shared session environment.
Windows System Resource Manager (WSRM) is a tool that has been around since Server 2003. It’s purpose is to granularly define resource limits as they pertain to specific users, sessions, applications or IIS app pools. WSRM’s use isn’t limited to RD Session Hosts, it just happens to be very useful in a shared environment. It should be noted that WSRM is a reactive tool, so you have to cross a certain threshold before the limits it imposes kick in. In the case of CPU, the host has to reach 70% utilization first, then any defined WSRM CPU limitation policies would begin to ratchet down the host. Best practices call for the use of targeted CPU limits to restrict resources, not memory limits. Use memory limits only if an application is exhibiting a memory consumption problem.
Here is a quick example of an allocation policy limiting IE to 25% CPU. This policy would need to be set as the managing policy for it to take affect after the host’s total CPU reached or exceeded 70%.


Another simpler option could be to use weighted remote sessions, categorizing users into basic, standard, and premium workloads to appropriately prioritize resources.

In the Server 2012 RC Add Roles and Features wizard, it is clearly called out that WSRM is now deprecated. Server 2012 will have the tool but the next server release in 4 years will not. Hopefully Microsoft has something up their sleeves to replace this tool or bolster the configurability of the fair sharing features.

References:
2012 list of deprecated features: http://technet.microsoft.com/en-us/library/hh831568.aspx
WSRM for Server 2012: http://technet.microsoft.com/library/hh997019
Server 2012 RC whitepaper: http://download.microsoft.com/download/5/D/B/5DB1C7BF-6286-4431-A244-438D4605DB1D/WS%202012%20White%20Paper_Hyper-V.pdf

BitLocker is a useful hard drive encryption tool supported by the Enterprise and Ultimate versions of Windows7. Recovery is handled through the use of 48-digit keys that are generated for each host running BitLocker. Best practice and common sense is to configure your environment so that the recovery keys are stored in Active Directory. There are a number of scenarios in which the use of these keys are required to gain access to the OS. By default only members of the Domain Admins group has access to these keys which is very inconvenient if you have a delegated support staff that are not domain admins. 

You can grant your support group full control to the AD container housing computers with BitLocker enabled and they will still not be able to see the recovery keys. Delegation of this access is done via a script. Just copy the text below, save it to a file with a .vbs extension, and run cscript whatever.vbs from a DC or workstation with a Domain Admin logged in. The only thing you need to change in this script is the second line: enter whatever your support AD group is called here. This all of course only applies to Server 2008/R2 and Windows7.

'To refer to other groups, change the group name (ex: change to "DOMAIN\Help Desk Staff")
strGroupName = "DOMAIN\Help Desk Staff" 

' --------------------------------------------------------------------------------
' Access Control Entry (ACE) constants
' --------------------------------------------------------------------------------

'- From the ADS_ACETYPE_ENUM enumeration
Const ADS_ACETYPE_ACCESS_ALLOWED_OBJECT      = &H5  'Allows an object to do something

'- From the ADS_ACEFLAG_ENUM enumeration
Const ADS_ACEFLAG_INHERIT_ACE                = &H2  'ACE applies to target and inherited child objects
Const ADS_ACEFLAG_INHERIT_ONLY_ACE           = &H8  'ACE does NOT apply to target (parent) object

'- From the ADS_RIGHTS_ENUM enumeration
Const ADS_RIGHT_DS_CONTROL_ACCESS      = &H100 'The right to view confidential attributes
Const ADS_RIGHT_DS_READ_PROP                 = &H10  ' The right to read attribute values

'- From the ADS_FLAGTYPE_ENUM enumeration
Const ADS_FLAG_OBJECT_TYPE_PRESENT           = &H1  'Target object type is present in the ACE
Const ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT = &H2  'Target inherited object type is present in the ACE

' --------------------------------------------------------------------------------
' BitLocker schema object GUID's
' --------------------------------------------------------------------------------

'- ms-FVE-RecoveryInformation object:
'  includes the BitLocker recovery password and key package attributes
SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION = "{EA715D30-8F53-40D0-BD1E-6109186D782C}"

'- ms-FVE-RecoveryPassword attribute: 48-digit numerical password
SCHEMA_GUID_MS_FVE_RECOVERYPASSWORD = "{43061AC1-C8AD-4CCC-B785-2BFAC20FC60A}"

'- ms-FVE-KeyPackage attribute: binary package for repairing damages
SCHEMA_GUID_MS_FVE_KEYPACKAGE = "{1FD55EA8-88A7-47DC-8129-0DAA97186A54}"

'- Computer object
SCHEMA_GUID_COMPUTER = "{BF967A86-0DE6-11D0-A285-00AA003049E2}"

'Reference: "Platform SDK: Active Directory Schema"

' --------------------------------------------------------------------------------
' Set up the ACE to allow reading of all BitLocker recovery information properties
' --------------------------------------------------------------------------------

Set objAce1 = createObject("AccessControlEntry")

objAce1.AceFlags = ADS_ACEFLAG_INHERIT_ACE + ADS_ACEFLAG_INHERIT_ONLY_ACE
objAce1.AceType = ADS_ACETYPE_ACCESS_ALLOWED_OBJECT
objAce1.Flags = ADS_FLAG_INHERITED_OBJECT_TYPE_PRESENT

objAce1.Trustee = strGroupName
objAce1.AccessMask = ADS_RIGHT_DS_CONTROL_ACCESS + ADS_RIGHT_DS_READ_PROP
objAce1.InheritedObjectType = SCHEMA_GUID_MS_FVE_RECOVERYINFORMATION

' Note: ObjectType is left blank above to allow reading of all properties

' --------------------------------------------------------------------------------
' Connect to Discretional ACL (DACL) for domain object
' --------------------------------------------------------------------------------

Set objRootLDAP = GetObject("LDAP://rootDSE")
strPathToDomain = "LDAP://" & objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com

Set objDomain = GetObject(strPathToDomain)

WScript.Echo "Accessing object: " + objDomain.Get("distinguishedName")

Set objDescriptor = objDomain.Get("ntSecurityDescriptor")
Set objDacl = objDescriptor.DiscretionaryAcl
 
' --------------------------------------------------------------------------------
' Add the ACEs to the Discretionary ACL (DACL) and set the DACL
' --------------------------------------------------------------------------------

objDacl.AddAce objAce1

objDescriptor.DiscretionaryAcl = objDacl
objDomain.Put "ntSecurityDescriptor", Array(objDescriptor)
objDomain.SetInfo

WScript.Echo "SUCCESS!"

Once the script has run successfully, the BitLocker Recovery tab will now be accessible in ADUC and ADAC.

 

Reference:

TechNet

Splitting DHCP scopes is a best practice that has been around for a very long time. The purpose is to spread a given IP scope across multiple DHCP servers in multiple locations for redundancy and load balancing. Let’s say that your company has two locations, A and B; Location A has two DHCP servers, location B has one. The IP schemes are different at each location but you want to ensure that DHCP services are available for all IP scopes at both should any of the DHCP servers ever have a problem. The best way to achieve this is to spread the scopes across all three servers. This is done by defining the scope on each server then configuring exclusions for the IP range that each server should not serve, to avoid overlap. While this was all possible in previous versions of Windows Server it had to be configured manually.

Server 2008 R2 makes this easier by adding a split-scope wizard in the DHCP MMC. First configure a DHCP scope as you normally would with the first and last IP address that you want to be dynamically assigned. Leave out the range of the IP space you intend to use for static assignments as we are only concerned with dynamic assignments. Once the scope has been defined and created it can be split by invoking the split-scope wizard in the advanced sub menu of the scope.

Once you have Selected the authorized server that you would like to add to the scope, the wizard will allow you to define the percentage of the address space that you want to give to the new server. Move the slider left and right to adjust the pool given to the new server you are configuring. If you plan to split the scope across 3 or more servers, do some quick math to determine how many addresses each should serve if you want to split the scope evenly. In the example below I am keeping 33% of the address space on the original server and giving 67% to the new server because I plan to split the scope again. The bottom portion of the window displays the exclusions that will be created on both the original host and new server.

Next you can configure a server offer delay so you can help shape which servers you want to be able to respond in which order. I intend to make my third server primary for this scope so will configure delays for both the host and added DHCP servers.

Before executing the split you are presented with a summary screen to ensure that your configuration is correct. Once you execute, the wizard will create an exclusion on the host server as well as create the new scope with exclusion on the added server. A time saver for sure!

The wizard runs through each required step and displays the result of each.

On the newly added server the scope is not automatically activated so if you made a mistake you can easily start over by deleting the new scope on the added server and the exclusion on the host server. Repeat this process on the second server to split the scope again ensuring an even split across all 3 servers. Once your configuration is solid all you need to do is activate the scope on each server you added it to.

Here is how the scope and exclusions look on each server after the split.

Original host:

2nd added server:

3rd added server:

As you can see best practice is automatically applied by defining the entire DHCP range on each server, then limiting the assignable range on each through an exclusion. Future adjustments can be made easily by changing the exclusion.

As a final step, make sure you have IP helpers configured in your switch on the proper VLAN interfaces so it knows where to send your client’s DHCPDISCOVER messages.

This one is easy to overlook and can have you scratching your head weeks to months later. Recently disk space has been mysteriously disappearing on a few select servers of mine. The free/used ratio was way out of whack with >75% of the disk being reported as used by Windows on certain drives. Auditing the drive reveals no culprit, with all visible files not consuming anything near what is being reported, including hidden files. System Volume Information reports 0 bytes and access is denied to this folder. If you use Windows Server Backup (WSB), in Server 2008 R2, and in particular VSS backups this can happen to you too (or VSS at all for that matter).

WSB uses VSS for backups and you have two choices in your backup sets: VSS full or copy backups.

 

In either case the backup job will create a Shadow Copy task on the volume pertaining to your backup. By default the shadow copy task is set to use no limit which will, eventually, completely consume your drive. The tricky part is that the space consumed by VSS is not visible in Windows Explorer and if you don’t set a hard limit on the shadow copy it can grow out of control.

Make sure to limit these and you should be ok. Changing no limit to use limit will immediately delete and free space on your server!

VSS settings are accessed by opening the properties of any drive in your server and selecting the Shadow Copies tab.

Despite whatever you may feel about UAC for use on your home PC, it is a great tool for desktops in the enterprise. “Run As” served its purpose well in the XP days almost a decade ago (has it really been that long?). As much as I like UAC in my enterprise for easy elevation of administrative tasks and accompanied profile virtualization, it’s not without its shortcomings. Namely, it is lacking the ability to selectively elevate specific applications that, for whatever reason, require administrative privileges, without the user knowing an administrator’s password. The solution used to be to grant the users administrative privileges outright or try to figure out the required permissions for every file write, registry call, or function the application would need to perform (subinACL). There has to be a better way. The principle of least privilege is a best practice that should be enforced in all environments, which serves to protect the organization as a whole as well as the individual user.

The problem:

I have several legacy applications with custom device drivers, built-in updaters, or program dependencies requiring change or write access to files that live in protected system directories. I don’t want the user to have to call for support every time they need to run the program and I don’t want to grant them administrative access.

While researching solutions we came across a product called PowerBroker:Desktops by BeyondTrust. They just re-branded this product so it used to exist as Privilege Manager. As advertised this solution was designed to address my problem exactly. Not only that this product supports the ability to elevate MSI’s and Active-X controls. Windows 7 and Server 2008 R2 are fully supported. The solution is comprised of two parts:

1. The Manager which contains the GPO editor extensions and RSOP snap-ins.
2. The Client which is a kernel-mode driver that lives on the user's PC including group policy client side extension and WMI namespace (deployable via MSI)

The driver on the client PC watches processes launched locally and checks against any configured GPO rules. If a rule exists for a launched process, the driver elevates the security token for that process based on settings in the rule. The added value for this method is that when applications are elevated the file system is not virtualized as is the case with a default “run as admin” operation. Additional privileges are added to the user’s security token for that specific process when it’s launched. This is like adding the user to the Administrators group temporarily just for that process for the duration it’s run (sudo).

The Manager piece is installed on your domain controllers, very straight forward.

Once installed the new features are immediately available in GPMC. Create a new or edit an existing GPO. You will see a new settings container under both the computer and user sections of the policy called Computer Security and User Security, respectively.

Before you can get to creating new policy items you will have to configure licensing. Along with the new settings containers, you should see a new button between View and Help called Privilege Manager. Open the Licensing tool and you will see 3 tabs: Local, GPO, and Request. You can generate a new request from the tool or simply import and activate a license you have received. To enable you first have to import the license you have purchased, then deploy it to the GPO in which you have enabled Privilege Manager features.

Deployment is done via the GPO License tab.

Once the license is active you can begin setting up policies. There are a number of options at your disposal which at first glance look a lot like a software restriction policy.

Once the program information is supplied you can assign permissions, privileges, and integrity settings to it. You can get very granular at each level if you need to.

Under the last tab, Common, you can apply filters to your policy much like a GPO Preference item.

Testing

To test, I have set up a path rule for cmd.exe that will elevate a non-administrative user to the builtin\administrators group for this process alone. The PowerBroker client can be deployed via GPO or other systems management solution to the specific PCs that need it. A single service will run on the client PCs called BeyondTrust Reporting Service. To prove that this solution works I will use a tool deployed with the client called Policy Monitor (polmon) as well as execute a privileged command from the prompt.

Logged into a PC with my test user John Doe, with PolMon running, I launch cmd.exe. Polmon displays that cmd.exe has been invoked and that there is a rule match for this application. The rule is parsed and John’s security token is elevated for the cmd process only, as configured.

With my elevated command prompt running, John executes a GPResult /R which under normal user mode only displays information about the user account. Computer related information is normally denied from being displayed without command prompt elevation. As you can see John was able to display RSOP results for both the user and computer accounts. Not only that the file system is not virtualized as you can see from the working directory. The user sees no UAC or other prompts, the application just works.

A quick note on licensing. PowerBroker:Desktops is licensed per enabled user that has the client installed. The license is installed at an OU level of your choosing and enabled per GPO. According to the documentation, each active user in an OU will be counted as a user for PowerBroker. So as far as the software is concerned any user in an OU that it can see is considered an active user. BeyondTrust has a few ways to deal with this, both extremely fair. You can use an enterprise license, enabling access for all users, which requires an annual true-up where you prove the actual number of users using the product. The other option is buying x number of licenses and they will provide some additional license padding for growth. User licenses will run in the $30-40 range each so depending on the size of your environment is very reasonable.

But here's the rub...BeyondTrust will only issue you a temporary 30-day license until their invoice is paid. Yep, even if you buy through the channel! So if your reseller (their partner) doesn't pay their invoice, guess what? No permanent license for you. If your reseller (their partner) has net 60 terms with them, guess what, no permanent license for you. This is an extremely paranoid way to license a product that I have honestly not seen ever in over a decade in this business! I am over 60 days now, on my second temp license, and am still waiting for my permanent lic. The product definitely works but their licensing policy is asinine. Buyer beware!

PowerBroker:Desktops is an extremely clean solution that works exactly as advertised. For those of us that have to deal with badly written or legacy applications requiring administrative access, this solution is a winner. I have ~20 users that will need this functionality so at the quoted price point this solution is a great deal with the amount of time and frustration it will save.