Category Archives: Deployment

Resizing an OSX partition on a VM hosted on ESXi.

Update 11/2/2014: We are successfully virtualizing Mavericks (10.9) and it is possible to resize disks online without having to go through the following guide. It still applies to Mountain Lion (10.8) and earlier versions.

One of the great things in vSphere 5.1 is that the Mac Pro is a fully supported server for ESXi. That means you can virtualize OSX on supported and recent hardware.

While the templating and integration is not as great as with Windows and Linux, you can deploy VMs in a reasonably short amount of time. Just make sure you don’t check the “Edit virtual hardware (Experimental)” box as it may blow your template up.

If you attempt to grow the disk, you will get a “Partition failed” error message in OSX “MediaKit reports partition (map) too small.”. No matter how many times you try it won’t work…

At this point you have 4 options:

Since I didn’t have time to place a purchase request and didn’t have much time, I used a PartedMagic iso I already had in one of my Datastores. Only to notice that the iso wouldn’t boot. This is due to the fact that OSX VMs are running in EFI boot mode only.

Fear not, there is a way to get it to boot:

  1. Shut your VM down.
  2. Right click > Edit Settings.
  3. Increase the disk space to the capacity you want.
  4. Go to the options tab, change the “Guest Operating System” to Windows and select any flavor of Windows in the drop down menu.
    From this:
    To this:
  5. Then, still in the Options screen, under “Advanced > Boot Options”, change the boot firmware from EFI to BIOS.
  6. Your VM should now be able to boot from the ISO.
  7. In PartedMagic, start Partition Editor, you should see an error message similar to this:
    Click Fix. If another dialog prompts you to fix something else, click Fix again.
  8. Add a FAT32 partition in the empty space.
  9. Click Apply.
  10. Shut down and revert the Guest OS and Boot Firmware options.
  11. Boot into OSX, delete the FAT32 partition and resize your main partition.
  12. You’re done.


Quick MDT 2012 facts

I’ve been quite busy lately so I’ll try to be quick… I would like to share my discoveries on MDT 2012 and the information I gathered while I was migrating from MDT 2010.

  • Mikael Nystrom’s step by step on how to update BIOS in MDT still works perfectly.
  • Andrew Barnes’ how to integrate BGInfo into WinPE still works, and even better, MDT 2012 comes with a 64-bit version of BGInfo (located at %deploymentshare%\Tools\x64).
  • It is no longer needed to have a custom pane to set local administrators in MDT 2012. Instead use the “SkipAdminAccounts=NO” property in CustomSettings.ini. Please note that the administrators accounts page only appears if you selected “Join a domain” as I mention on the TechNet Forums.
  • Thanks to Michael Niehaus, DaRT integration is now fully supported in MDT 2012. I talked about this earlier but it’s always good to reiterate the benefits of software assurance.
  • A very interesting new feature of MDT 2012 is monitoring. It can be enabled in a few simple steps: Navigate to your deployment share properties, go to the last tab called “Monitoring”, check the box called “Enable monitoring for this deployment share”. Then click OK. It should work right away… A good way to check is to look at your CustomSettings.ini for a new line called “EventService=http://myserver.corp/“. Is you run into issues there is always this good troubleshooting article. Used in conjonction with DaRT, you can remotely control deployments from a central location.
  • Another feature that might not be actually that new but still useful is the “SLSHARE=” property. It allows you to set a network share where the logs are written during the deployment. This is particularly useful when your helpdesk people forget to capture logs if a deployment fails. A good security practice it to set a sticky bit, using the user directory technique on that particular folder since logs may contain sensitive information.
  • You are now able to use only one (32-bit) boot image to initiate both 32-bit and 64-bit deployments. A word of caution, though, if you need to use DaRT to repair an install you will need to boot the appropriate architecture.


Integrate Microsoft Diagnostics and Recovery Tools (DaRT) into the MDT boot image

If you’re running MDT 2012, please read Michael Niehaus’ post:

I recently found out Microsoft Diagnostics and Recovery Tools (I’ll refer to it as DaRT thereafter) was quite handy. It is part of Microsoft Desktop Optimization Pack, which is available for free if you’re covered by Software Assurance.

So basically the goal here it to integrate the tools available in DaRT into the WinPE boot image generated by MDT.

Looks handy, doesn’t it?

DaRT is distributed as an installer which requires Windows 7 setup files to generate a custom WIM encapsulated into an ISO. Sounds quite cool but that’s one more thing to maintain and update with new drivers… Since the DaRT installer uses WinPE that shouldn’t be too hard to figure out a way to add some more files to make it work.

Took me a little while to figure out but it ended up working so I’m sharing the technique with you guys:

You will need: Windows AIK, the DaRT installer, MDT 2010 and some kind of archive utility like 7-zip.

You will also need to do this twice, once for the x86 Boot Image and once for the x64 Boot Image.

  1. Acquire the MS DaRT installers for x86 and x64 located in the MDOP iso available through MS Volume Licensing or MSDN.
  2. Follow the wizard to create the 2 ISOs, 1 for x86 and the other one for x64.
  3. Create a directory called the following directories: c:\DaRT\ERD and c:\DaRT\files (or whatever/wherever you like).
  4. Expand the ISOs to c:\DaRT\ERD\x86 and c:\DaRT\ERD\x64 (using 7-zip for example).
  5. Open a privileged command prompt and use the following command:
    C:Program FilesWindows AIKToolsServicing>dism /Mount-Wim /wimfile:c:\DaRT\ERD\x86\sources\boot.wim /mountdir:c:\DaRT\files\x86 /index:1
    C:Program FilesWindows AIKToolsServicing>dism /Mount-Wim /wimfile:c:\DaRT\ERD\x64\sources\boot.wim /mountdir:c:\DaRT\files\x64 /index:1
  6. At this point you can delete c:\DaRT\ERD if you want.
  7. Go to c:\DaRT\files\x86 and x64. You should see the following directories:
    Program Files
    Program Data
  8. Delete Program Data and Users.
  9. Go to Program Files, delete all directories but “Standalone System Sweeper”.
  10. Go to sources, delete all directories but “recovery”.
  11. Go to Windows, delete all directories but “System32”. Then, under System32 sort files by date. Delete all files and folders that are not timestamped as of the day you created the ISO. That should leave you with 28 files (37 if you have the debugging tools). Additionally, delete winpeshl.ini as it interferes with the MDT wizard.
  12. At this point we’re pretty much done.
  13. Go to MDT, right click on your Deployment Share > Properties.
  14. In both Windows PE x86 Settings or Windows PE x64 Settings at the Extra Directory to add, specify C:\DaRT\files\x86 for the x86 boot image and C:\DaRT\files\x64 for the x64 boot image (or any other folder you may already be using/wanting to use).
  15. Rebuild your deployment share.
You’re done.

Make an MDT task sequence resolution independent.

You will often find yourself with a deployed computer that doesn’t match the resolution it’s supposed to use. It’s quite annoying, especially on laptops (have you seen how ugly Windows is when displayed at 1024×768 on a 1920×1200 screen?).

There is a very easy way around that:
  • Go to your task sequence properties.
  • Go to the OS info tab then click on “Edit Unattend.xml”
  • WSIM will launch, navigate to: Unattend\Components\1 windowsPE\x86_Microsoft-Windows-Setup_neutral (replace x86 with x64 if using a 64-bit OS, of course)
  • Delete the Display component.
  • Navigate to Unattend\Components\7 oobeSystem\x86_Microsoft-Windows-Setup_neutral (replace x86 with x64 if using a 64-bit OS, of course)
  • Delete the Display component.
  • Save and exit WSIM.
Congrats, you now have a resolution independent task sequence. It is highly recommended to have up to date drivers available in your deployment process.

Target an advertisement based on the software version in SCCM

Let’s say we want to advertise an update to Adobe Reader only to clients with outdated versions (anything older than 10.0.1).

  • Create a new collection.
  • Edit the membership rules.
  • Click on Edit Query Statement.
  • At the bottom press “Show Query Language”.
  • Paste the following:

  • select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
    SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Adobe Reader %" and SMS_G_System_ADD_REMOVE_PROGRAMS.Version != "10.0.1"

Make edits to match the DisplayName and Version according to the results you want.
You’re good to go.


ConfigMgr Firewall exceptions for Client deployment.

To enable ConfigMgr client deployment, create the following GPO (or update if you already have one):

Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Firewall > Domain Profile
Windows Firewall: Allow inbound file and printer sharing exception: Enabled
Allow unsolicited incoming messages from these IP addresses: SCCM IP Address
Windows Firewall: Allow inbound remote administration exception Enabled
Allow unsolicited incoming messages from these IP addresses: SCCM IP Address

[UPDATED] Adobe Reader 9/X Clean Deployment

What I wrote about Adobe Reader MSI patching has a major flaw: you cannot under any circumstances update Adobe Reader after installing it with the modified MSI. I had to find another way…
Good news, it’s a lot easier now.
  • First of all obtain the latest Adobe Reader Installer from this page:
  • Extract the contents of the downloaded archive using the following command: InstallerName.exe -nos_ne which will extract the contents to: %userprofile%\AppData\Local\AdobeReader 9.0\Setup Files\READER9 for Reader 9 and C:\ProgramData\Adobe\Setup… for Reader X.
  • Optional for X (since Adobe seems to have caught up): download updates from this page, then add them to the default install by editing the setup.ini file with the following line in the [Product] section:
    This should allow you to install Adobe Reader in its most up to date version without too much headache.
  • Download the Adobe Customization Wizard for 9 or Adobe Customization Wizard for X and set the settings you like, make sure an AcroRead.mst file is created next to the MSI. That will enable you to run setup.exe without switches in a completely unattended mode.