Windows 8 & Multi-Tenancy AD

So apparently all the new hyped-up multi-tenant features of Windows 8 that Microsoft and all the blogs have been slathering over is all related to Hyper-V and how you can use it to do multi-tenancy (MT). Their version of MT is literally only talking about how you can have multiple VM’s running in Hyper-V and how they can be completely separated on the same box (good article here ). Apparently it does this by vlan tagging – which I didn’t realize wasn’t already an option in Hyper-V. We’ve been doing this in ESX for years the exact same way.

What this means is that AD is still normal Windows Active Directory. Sure there are some nice, new, bells and whistles, and a whole new, clunky interface, but underneath it’s still the same AD it always was. This makes me sad in this day of “Cloud” and everyone having to have their own public and private cloud, the buzz words like IaaS, SaaS, etc. Still no multi-tenant AD. And for most companies and customers out there who don’t want to build a whole new AD to support a half dozen servers, we’re still back to the old ways of setting custom AD permissions on OU’s and objects. Mark me sad.

To sum up: multi-tenancy in Win 8 is just Hyper-V with vlan-tagging. Stuff we’ve been able to do for years, anyway.

Back to the drawing board for me!



If you don’t know what RTFM means, go google that before you get any further. I’m trying to keep my potty mouth off the web.

Okay, done?

Over the past couple of months I’ve been playing with various Windows Patching Solutions. First was SCCM 2012 (bust), CA Patch Manager (mostly bust), and now VMWare Configuration Manager (not sure yet). I’m a big believer in just popping in the CD/DVD and hitting setup and letting the chips fall where they may. I feel like that’s the best way to learn and a good product usually lets you get away with it.

Not one of these 3 products has allowed me to do this. Although I’ve certainly tried. I run into various problems, stupid issues, and just plain old “Huh?” moments that I wouldn’t have or shouldn’t have if I’d just plain RTFM. Annoying, yes, but I guess since these are complex products I can understand it. (The old sage in me thinks you should be able to click Setup, run through the wizard, then just add the machines you want to manage, type in your creds, and go.) But in these cases that did nothing but waste days/weeks of my time.

So the takeaway from this? Yeah, I’m still going to surge forward without reading the manual, but when I run into issues maybe I’ll skate back and start over there 🙂


vCloud Director and clustered Guest OS

Just a quick post to try to save some effort here…

After a few days of investigation and testing (and speaking to a VMWare consultant) it’s been determined that the current version of vCloud Director does NOT support clustering a guest OS. vCD does not have the ability to create shared disk resources and even if you try to bypass it by going directly to the vCenter instance and edit the hardware yourself (unsupported by VMWare, btw), all the options for creating a shared SCSI controller/disk are grayed out. vCD overrides the ability to do any of this.

Bummer, but not completely unexpected.

vCloud director and LDAP

Started with a new client recently who is using ESX 5 and vCloud Director, so I should be able to branch these posts out a bit!

Ran into an interesting problem almost immediately. They’ve got several Organization vDC’s set up and are trying to get them each to authenticate against Active Directory groups using Custom LDAP queries. An account was already created and the LDAP connection was set up.

It was able to pull in the groups successfully and when you ran a test against AD everything seemed to be working correctly, however when a user tried to log into that vDC who was in the AD group, they couldn’t log in.

We fooled around with turning SSL on and off, changing the AD Domain Controller (DC) it was pointed to.. all that jazz. And nothing made a difference.

The Custom LDAP setup has a place to run a test query against LDAP and pull up specific users and what it came back with was kind of out of whack. It would pull most of the user information (name, description, etc.) but wouldn’t pull back any group information on them. We also played around with the LDAP mappings and changing what information it pulled, but that did nothing either.

I finally did what I should’ve done from the beginning and looked at the account that was being used for the connection. It’s only membership was in Domain Users. Okay, that’s an easy test. I went to one of my test accounts that wasn’t working (and was in the AD group we were sync’ed with) and granted the LDAP connection account Full Control to my test account.

And voila, it worked!

Took out the security perms and could no longer get in, so security was obviously the problem.

As it turns out, Domain Users does not have the permissions to pull the group membership on users. That is not a public field. As a work around (because we didn’t want to grant that account any more permissions than it needed), we placed it in the domain RAS and IAS group (which did have the permission). This is only a temp fix as you still need to modify the adminsdholder to allow it to pull group membership for administrators, but at least it’s a step in the right direction!