First, I copied the folder that I keep the unattend.xml files to my programs share. I keep x86 and x64 unattend.xml’s in the same folder, named appropriately. As I have specific requirements (keyboard settings, etc.), and I hope that this solution will make my workgroup deployments easier, I decided that I should duplicate these files and add in the xml for the certificates to each one. I then created the certificates as per James’ blog:

Step 1 – Generate a Client Certificate

This is the easy bit.  You just need a valid PKI client certificate which gets exported, along with its private key for importing later on.  For this you just need a domain-joined system which can talk to the CA.

The certificate template I used was the same as the ConfigMgr Client Certificate template I created to support HTTPS communications in CM12.  So, in the Certification Authority console:

1. Right-click “Certificate Templates” and select “Manage”;
2. Right-click “ConfigMgr Client Certificate” and select “Duplicate Template”;
3. Select “Windows Server 2003 Enterprise”;
4. In the General tab, change the certificate Template Display Name to “ConfigMgr Workgroup Client Certificate”;
5. In the Request Handling tab, tick “Allow private key to be exported”;
6. In the Subject Name tab, select “Supply in the request”;
7. In the Security tab, select “Domain Computers” and untick the “Autoenroll” permission;
8. Select OK.

Back in the Certificate Authority console, right-click Certificate Templates and choose “New” –> “Certificate Template to Issue”.  Choose the newly-created template from the list and select OK.

Now, on a domain system (it can even be the CA), launch the Certificate MMC snap-in for the Local Computer:

1. Go to Personal –> Certificates;
2. Right-click Certificates and select “All Tasks”, “Request New Certificate”;
3. Select “Active Directory Enrolment Policy” and click Next;
4. Tick “ConfigMgr Workgroup Client Certificate” and click the link directly underneath which is prompting for more information;
5. In the Subject tab, select “Common Name” from the Subject Name drop-down and type in “Workgroup PKI” in the Value field;
6. Select Add, and OK;
7. Select Enrol.

The new certificate should now appear in the MMC window.  Right-click the certificate and select All Tasks –> Export:

1. In the Export Private Key window, select “Yes, export the private key”;
2. In the Export File Format windows, tick “Include all the certificates….” and “Export all extended permissions”;
3. Select and confirm a password, and then a location for the PFX file;
4. Export completed.

Once I had the exported certificate, I copied this into the folder with the unattend.xml files. I then made the edits to the unattend.xml files, according to the relevant architecture as per James’ blog, but with a slight change, as per the comments, which I have bolded:

On a system with the Windows Automated Installation Kit (WAIK) installed, launch System Image Manager and open the Unattend.xml.  Make sure that it’s associated with a Windows catalog for the correct architecture version of Windows (eg: x86 or x64)

In the Windows Image section:

1. Expand Components;
2. Expand amd64_Microsoft-Windows-Deployment_6.1.7600.16385_neutral (assuming your architecture is x64);
3. Expand RunSynchronous;
4. Right-click RunSynchronousCommand and select “Add setting to Pass 4 specialize”.

In the Answer File section:

1. Navigate to the newly-added setting under pass 4 specialize;
2. Change the Description to “Import PFX”;
3. Change the Order to the last in the list (eg: Order = 3);
4. Change the Path to “cmd /c certutil -f -p {password} -importpfx c:\_SMSTaskSequence\Packages\{PackageID}\nameofyourcert.pfx” (without the quotes);
5. Ensure the Will Reboot is set to “Never”;
6. Expand RunSynchronousCommand and right-click “Credentials” and select Delete.

Save and exit System Image Manager.  Make sure that the Settings package is updated in the Configuration Manager console so that the latest version is copied to the distribution point.

Once I had saved the unattend.xml files, I then created a package in SCCM from these files and called it “workgroup settings”.

I didn’t need to create a new Configuration Manager Workgroup Package as per James’s instructions (well, I created one, but due to an oversight, I didn’t actually use it!).

Once the package is complete and distributed, create a new “build and capture task sequence”. I used the install.wim file from each operating systems DVD’s sources folder for the task sequence, and the Configuration Manager Client Package. Once you’ve created the task sequence, follow the below steps:

1: Go to the step “Partition Disk 0 – BIOS” and delete the BCD partition, and then mark the Windows primary partition as the boot partition.
2. In the “Apply Operating System” step, tick the box “use an unattended or Sysprep answer file for a custom installation” box, and then select your “workgroup settings” and choose the unattend.xml relevant to your architecture.
3. In the “Setup Windows and Configuration Manager”, change the installation properties for the Configuration Manager Client Package to DNSSUFFIX={your dns suffix} CCMHTTPSSTATE=31.

I then proceeded to deploy the task sequence to the collection I was targeting, making sure that on the distribution tab, I ticked the “when no local distribution point is available” box.

Once I had done this, I was able to build and capture machines for Windows 7, 8 and 8.1 (and I’ve not even installed 2012 R2 yet!). Next step is to see if I can apply what I have learned here to building workgroup clients. I’ll let you know how it goes!

I was able to fix this by downloading this program. By running the exe file, I was able to restore the default settings for this menu and even add in some more entries.

First drag an Initiate Data unit from the runbook control section. I renamed this to “User Info”. You can use whatever fields you want here, but the ones I used are as below:

These will be linked to later in the runbook. Click finish and then drag and link a generate random text control from the utilities section.

Set this up according to your complexity requirements, I did this as above. The next step is to create a some variables. Drag a run .net script control from the system section, and link it to the password step. I used a basic PowerShell script to allocate a SamName from the first name and last name. You can edit this according to your organisations specifications, but my organisation uses first initial, last name, so this script is geared to that. It also truncates the SamName so that it doesn’t exceed the 20 character maximum.

This is the script:

$Fname = "First Name"
$Lname = "Last name"
$Phone = "Phone Number"
$Title = "Title"
$Department = "Department"
$Sam=$FName.substring(0,1)+$LName
$max=$Sam.Length
if ($max -gt 20) {$max=20}
$Sam=$Sam.Substring(0,$max)
$Alias=$Sam

Where there are descriptions between the quote marks, these need to be replaced with subscriptions to the corresponding data from the User Info step. To do this, delete the description and then right click between the quote marks, and choose subscribe > publish data. From the drop down choose UserInfo and then select the corresponding piece of data. This will end up looking something like this:

I tried scripting more information such as address details, OU and profile data, but I found that for some reason Orchestrator was pulling the wrong data for the variable, so I decided to use a different approach. However, if you are interested in how I did this, please let me know and I will update the post.

Next we need to publish these variables so that we can use them for the create user step. Click on the Published Data tab, and then click on add. This presents the box below:

This small script only needs to have department and SamName published, but depending on what you script, you can publish anything you need here. Notice that the variable name does not have the $ at the beginning.

For the next step bring a create user control from the Active Directory section. Link this to the variables control, and then right click on the link, and choose properties. This is where you can insert a condition based on the department variable so that users in that department get a specific set of properties.

You can specify the details for the new user, and the rest of the process, and then copy those controls, and paste them in again, link them with a different condition and then change anything that needs to be different in the create user control for the new branch.

Open the Create User control and on the properties tab, specify the AD connection of the domain you want the user added to (you can use this to create one runbook that creates users across multiple domains based entirely on their department!). There are instructions for connecting to AD here.

Click on Optional Properties, and choose the ones that are relevant to your organisation. I went with:

Here is how I configured each of the fields. Words within {} are subscriptions from previous controls:

Common Name: “{last name from userinfo}\, {first name from userinfo}”

I should point out this is for last name, first name, and that the \ is required for powershell to recognise the comma. The quotes are also required.

City: Enter the City
Company: Enter the Company
Department: {Department from userinfo}
Description: Whatever you want, however I used {Title from userinfo}
Display Name: “{last name from userinfo}\, {first name from userinfo}”
First Name: {First Name from userinfo}
Home Directory: \\servername\sharename\{SamName from variables}
Home Drive: Map your drive letter here if you use this.
Last Name: {Last Name from userinfo}
Container Distinguished Name: This is the OU for the users department in the format OU=Sales,OU=Users,DC=int,DC=domain,DC=local
Password: {Random Text from generate password}
Office: Enter the Office Name
Postal Code: Enter the Office Post Code/Zip
Profile Path: \\servername\sharename\{SamName from Variables}
SAM Account Name: {SamName from variables}
Login Script: Enter login script name (script.bat)
Phone Number: {Phone from userinfo}
Title: {Title from userinfo}
Web Page: Enter default website
User Principle Name: {SamName from Variables}@int.domain.local

Next drag an enable user control over from the AD section and link this to create user. Set the AD connection and subscribe Distinguished Name to {Distinguished name from create user}.

Next drag an enable mailbox control from the Exchange Admin section and link to enable user, set the Exchange connection and subscribe Distinguished Name to {Distinguished name from enable user}.

For the last step, drag a send email control over from the email section. I set this up as below:

On the connect tab, add your SMTP details and send from address, and then specify any required security details. Once you have done this, run it through the runbook tester, and you should be ready to go.

I’ll do a post on connecting the runbook to System Center System Manager at a later date.

After opening Runbook Designer, go to Options and select either System Center Operations Manager or System Center System Manager depending on which one you want to configure. Click add on the dialogue box and you will be presented with this box:

In the name box, type the name you want to refer to the connection as.

Server is the FQDN of your SCOM/SCSM server.

Domain is your domain name, username is in the format <username>, which is an administrative user of that server and the password is the password for that account.

Adjust the monitoring intervals according to your needs, bearing in mind that this will affect network traffic.

Once you have input all the information, test the connection and you’re ready to start creating runbooks for SCOM and SCSM.

In the next post I will describe connecting System Center Virtual Machine Manager.

Open Runbook Designer, click options and then “System Center Configuration Manager”. In the dialogue box click add, then you will be presented with this box:

Name should be the name of the connection.

Server is the FQDN SCCM CAS or Primary Server depending on your infrastructure.

Username is an SCCM administrator in the format domain\username

The password is the password for the above account.

After you have input the information you can click on Test Connection to make sure everything is good!

The next post will deal with System Center Operations Manager and System Manager.

In order to integrate it with Active Directory, you need to first download and install the integration packs to your runbook server. There is a guide to this here. You should note that if you already have System Center 2012 integration packs installed, you will need to un-deploy them and delete them from the runbook server before you can install the SP1 integration packs.

After you have deployed the integration packs, you will need to open runbook designer and go to Options > Active Directory. Click add on the box that comes up, and you will be presented with the following box:

The settings should be entered in the following format:

Username: domain\username – This user must be one with domain administrator rights.

Password: This is the password for the account used in the above step.

Configuration Domain Controller Name (FQDN): domaincontroller.domainsuffix.com – This should ideally be your primary domain controller as this will reduce the amount of time needed for Orchestrator steps to replicate.

Configuration Default Parent Container: This is the distinguished name of your user container, and should be in the format “OU=Users,DC=int,DC=domain,DC=local”.

You will need to add an Active Directory instance for every domain in your forest.

Click OK and you are ready to automate Active Directory tasks. The next post will cover SCCM.

When a user sends mail from a delegated mailbox, by default, the sent item goes into their own mailbox. To change this behavior so that the mail goes into the delegated mailbox’s sent items:

Set-MailboxSentItemsConfiguration –Identity ‘CEO Mailbox’ –SendAsItemsCopiedTo SenderAndFrom –SendOnBehalfOfItemsCopiedTo SenderAndFrom

To grant a user editor rights to a shared calendar on a mailbox:

Add-MailboxFolderPermission -Identity ‘alias:\Calendar’ -User ‘username’  -AccessRights Reviewer

I’ve always found the posts at www.windows-noob.com to be a bit of a godsend. This post by @ncbrady was particularly helpful. With a few minor adjustments, you can make this work for the ElitePad too, and presumably any other windows tablet.

Firstly, make sure you are deploying the correct architecture. The ElitePad is 32-bit, so make sure you are using the x86 Windows 8 image.

Secondly, you don’t need to add any of the HP WinPE drivers to the boot image. Honestly, they do more harm than good. Don’t do it. A clean boot image will happily do the job.

If you don’t have the attachable keyboard, make sure you do use a USB hub and attach a keyboard and mouse. The touch screen doesn’t work from the boot image, and so you need to find a way to click the all important “next” button and also set the variable.

Once the machine is built, the drive is bitlockered, but you still need to go in and actually turn it on.

Make some adjustments to your process according to your environment, but the above blog post has everything in it you need to get started.

Whereas in a client version of windows, you can remove this using the disk cleanup tool, this is not possible on Windows Server.

For this you will need to follow the below procedure.

From the start menu, type CMD into the search facility or run box, and then right click on it and “run as administrator”.

Type the following at the command prompt, type the following and run then in sequence:

takeown /F <DriveLetter>:\<FolderName>\* /R /A

cacls <DriveLetter>:\<FolderName>\*.* /T /grant administrators:F

rmdir /S /Q  <DriveLetter>:\<FolderName>\