About the UserAccountControl attribute


When working with MIM you will sooner or later have to deal directly with the UserAccountControl Active Directory attribute. This attribute defines account options, and we use it most prevalently to enable and disable users, but there are a lot of other options as well. These options are stored in a binary value as bit flags, where each bit defines a specific function.

Bit number 1 (or 2 if you are not used to zero-based numbering) defines whether or not an account is enabled. Bit number 9 defines an account as a normal account. Thus, a normal disabled account will have bits 1 and 9 set to one. As long as no other bits are set, the decimal value is 2^9 + 2^1 = 514 or (0010 0000 0010). If we enable the account, the value is 2^9 = 512 (0010 0000 0000).

In MIM we are usually presented with decimal values. These are easier to read, but not necessarily easier to understand.

Continue reading “About the UserAccountControl attribute”

MIM LAB 1: Prepare a domain controller

This post is a part of a series. The chapter index is located here.

We will look at:

  • Installing ADDS
  • Creating a domain
  • Configuring DNS
  • Creating a basic OU structure
  • Creating users and groups required for the MIM installation

Continue reading “MIM LAB 1: Prepare a domain controller”

MIM 2016 Lab series



These are the notes from my adventures installing a MIM 2016 SP1 lab/dev environment. I am using https://docs.microsoft.com/en-us/microsoft-identity-manager/microsoft-identity-manager-deploy as a guide, so make sure you read it as well. A certain proficiency with Windows 2016 and AD is a prerequisite to understand this series. All servers in this lab are running Windows 2016 Datacenter with GUI, and I am using SQL Server 2016. Thus, I deviate from the guide mentioned above which is based on Win 2012 R2 and SQL 2014.


My plan is to use three VMs:

  • DC01, the domain controller.
  • IM01: SQL Server, MIM Sync, MIM Service.
  • IM02: Exchange and other stuff that should not be co-located with the software on IM01. I considered naming it Exchange, but there may come a time when I will install other stuff on it related to MIM.

I am creating a separate domain in a new forest for this lab, aptly named mim.local, as I am going to test multi-forest MIM deployments. This will certainly add some spice to the process…

Be aware, this is a lab. Do not use this setup as-is in production. I have tried to add remarks for what I would do different in production along the way.


The will be a series, and new chapters will be added as I get time. The chapters are listed below.


This tool was created as a quick fix for a problem a coworker had in System Center Configuration Manager (SCCM): moving a re-imaged computer to it’s final location. I don’t really know all that much about SCCM, but his problem was to find a script that was able to move the current computer to a new OU based on a special environment variable defined in the task sequence (OSDDomainOUName).

We tried to utilize several vb scripts he found searching the web to no avail. In the end I got tired of this and created a small command line interface to one of my existing code libraries who already had the ability to move a computer.


As usual, this tool is provided without any warranty whatsoever. Use at your own risk, and don’t blame me if it doesn’t work. My coworker has deployed it in production successfully, but I can not guarantee that it will work in your environment. Constructive comments are appreciated, but I can’t promise a swift reply.


The tool itself is fairly simple to use, albeit not necessarily easy to integrate into SCCM. It has two command line options, but in the typical scenario you will only use the /D: for destination. The destination is the name of the OU you want to move the current computer to in FQDN format, e.g. LDAP://cn=ou,DC=test,DC=local. This will typically be collected from the %OSDDomainOUName% environment variable mentioned above.

You can use the /S: option to move another computer than the one you are currently executing the program at.

The user executing the program need to have the necessary domain permissions to perform the operation. In short, domain admin or at least delegated admin for the OUs in question.

The self extracting exe below contains a msi setup package that can be installed (and later uninstalled) as part of the task sequence. If you wish, you can just copy the .exe and .dll files and it will usually work.

In SCCM, you have to define the OSDDomainOUName variable for each collection were you want to use this tool. Then, you have to add a step  for running the command AFTER the “Set up Windows and Configuration Manager” step. See screenshots for an example.