Copy AD group memberships from a source user to other users

Note: This blogpost is also posted on the peppercrew website.

This post is going to be short, but effective. One of those mondaine tasks you get to do as an IT administrator is assigning users to security groups for access to resources in the domain. Usually, when you ask the person making this request which security groups the user account needs membership for, they’ll tell you to use some other user account as a reference. Sometime you’ll even get a list of users that need to have the same memberships.

Screensaver not working in a XenDesktop VDI environment

Note: This blogpost is also posted on the PepperCrew website.

The Story

I was troubleshooting some RES Workspace Manager (RES WM) issues in a customer’s XenDesktop 7.x (Citrix) environment when I came across the following issue: The screensaver didn’t start automatically, even though I had forced a screensaver through RES WM. After some research I’d come to the conclusion that this was a known issue in XenDesktop 7.x. Apparently Citrix has decided to disable Screen savers and power-save options in XenDesktop. They provide the following solution in their eDocs documentation:

Building a better Orchestrator Runbook testing tool

The Story

I recently started working on a project that required me to create a lot of System Center Orchestrator Runbooks. I quickly became frustrated with the Runbook Tester application because it would only run while a runbook is checked out, rendering the runbook useless for colleagues that needed it. Also the application would run under your current account instead of the orchestrator service account so I couldn’t trust it’s results (I know I can log in under that account but the point is: I really shouldn’t have to). I then switched to the Orchestrator Console to test the runbooks. This takes care of all of the issues above but was still frustrating to test with for the following reason: everytime I start a runbook I have to manualy enter all the parameters. The more input parameters your runbook has, the longer it takes to test it. And then if I test the runbook and it fails within ten seconds I have to start all over again! Say it with me, folks: frustrating!

After a few days of self-pity and blaming Microsoft for my sorrows I thought to myself: If you can’t get the proper tools for the product, build one yourself! So I went to my favorite Powershell tool: Sapien Powershell Studio. I used some Microsoft MSDN pages to create my own set of functions to utilize the orchestrator web service, only to find out after the fact that someone else had build a cool module for it (check out this codeplex site). Then I build a GUI around it. I think its my best work yet!

Create a custom Deployment Wizard pane for Updates (MDT)

Note: This blogpost is also posted on the peppercrew website.

The Story

One of the great things about the Microsoft Deployment Toolkit (MDT) is that it’s a very open product. All the scripts are customizable, including the Deployment Wizard. We can add new functionality to the deployment procedure and add wizard pages so we can choose to use those new functions (or not) with each new deployment. Microsoft encourages creativity for this particular product. One of the functions I wanted to create a wizard page for was the deployment of updates. I wanted to be able to choose between a quick OS deployment for test purposes (no updates) and a slower, more production worthy deployment (with updates). And since I take my deployment VM on the road with me, I wanted the ability to choose if the updates are downloaded from Microsoft Update or a clients’ WSUS server. The result looks like this:

Here’s how it’s done:

Add WSUS Target Group option to MDT deployments

Note: This blogpost is also posted on the peppercrew website.

The Story

One of the great features you get when deploying a Windows operating system using my favorite deployment tool, the Microsoft Deployment Toolkit (MDT), is the ability to update the OS using either Windows Update or a local WSUS server. The latter is obviously preferred because it’s a lot quicker and you have better control over what updates you want to install. WSUS has a feature called Target groups, which you can utilize for managing update approvals for a group of computers. This way you’ll be able to approve or decline specific updates for  Remote Desktop Session hosts or Exchange servers etc. While MDT let’s you specify a WSUS server to get updates from there’s no way to specify the target group you want to receive updates from. Let’s fix that, shall we?