In part 2
I started to write about Active Directory and how to get a single domain to work with multiple organisations, so lets get back to AD and look at how HMC helps with it? Well what HMC does to AD is it gives you a way to setup the OU structure and it sets up a number of properties on the AD object.
One of the great things about the OU structure is that allows you to have a top level organisation (which is called the hosting company), a second level organisation/s (the resellers) and a third level organisation/s (the customers). The second level is very exciting as this is actually the level at which sales are done and due to the structure the multiple resellers can exist and can work with their customer base but are secured away from other customers and resellers. If you thinking of white boxing a hosting solution, this is how it is done.
Security is obviously taken into account by the HMC engine will let a administrator on a hosting company level manage anyone within the system, on the reseller level you can work add accounts to your own account and any of your customer via the web interface. But does this mean you will spend your admin days in the web interface? Definitely not! Your AD skills still apply and you can still manage users, computers, set group policies and reset passwords etc... But you should be doing provisioning (creation of items) through the web interface or the engine as it will save you from having to edit AD properties manually later on for instance. If you aren't looking at white boxing it then you would just have your hosting company and one reseller and then various organisations as customers.
You may have picked up that I said you can use the engine to provision and you may have thought that meant you need to use the SDK and write code, well you don't have to! Microsoft have actually included a tool called Provtest which is a command line tool on your HMC server which you pass an XML file to. It takes the file and parses it and pushes it to the engine and displays the result. This is actually the same way the SDK works, in that you pass XML to the web services or COM+ object to do things. Microsoft also includes many samples with HMC, and even more in the SDK. So what you may find yourself doing it a lot of that, especially when you get to Exchange management.
One of the ways HMC also modifies the AD object properties is that the login name gets set in such a way that it allows each customer to have their own domain name (sort of) however it's just on the AD account name. This isn't an easy concept to grasp without an example, so lets say the hosting company domain is Contoso.local, and lets say that a customer named Northwind signs up with one of their resellers (who the reseller is, is not important). The Northwind guys decide they want their domain to be Northwind.com, so via the web interface they add Fred and set his login to be [email protected]. What HMC does is set the AD account name to [email protected], however in the background it sets the SAM account name (or the pre-Windows 2000 name) to be contoso.local\fred_northwind.. Yes, it should be dot-dot, the first dot for the SAM account and second for the grammar. So all customers are on the same domain at the core but the account name is what they would use to login to OWA, their machine or an application like MSCRM.
The SAM account name is vitally important still as most applications don't like using account name internally. For example MSCRM allows you to login with the account name, but when adding users individually you cannot use the account name, you must use the SAM account name. Odd though the multiple user add option does work with the account name. This is a annoying problem as it means you need to expose the (ugly) SAM name to your customers and if you have named you hosting level with something distinctive it could limit your white box ability!
This disconnect between account name and SAM account is a massive pain in ass for service accounts too, as I lost way too much time during the deployment on many services just retyping passwords and resetting them because I thought I was losing my mind. Only to realise that the application didn't like something in the username and wanted the SAM account name. The worst experience I had with passwords during all of this was with Forefront, where it not only didn't like the account name but also didn't like the fact the domain name (on the hosting company level) had a dot in it.
The security isn’t perfect though as there are times when you can see all users in the system. In an earlier version of HMC, there was a problem with the address books where everyone could see everyone but that has been corrected. For MSCRM though the add multiple user interface shows all users when you hit the lookup if you have not configured MSCRM correctly. I’ll come back to this point later in the series when I take about MOSS.