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!

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!

Provisioning Server 5.6 and cross-platform VHD’s, Part 1

So if you’re like anyone, you actually buy new hardware. Today you’ve got a BL460c G5, tomorrow you can only buy G6’s. Or G7’s. You’ve also got an ESX environment and maybe even a Hyper-V server stashed somewhere. The beauty of Citrix PVS and streaming your VHD’s is that you can have bare metal just sitting there… sitting there doing nothing, and you can PXE boot it and be on your way.

You also like to stream your images to your VM’s, cause hey… You can virtualize your hardware, why not virtualize the OS you put on it?

And maybe you’ve got that Hyper-V server sitting over there, off to the side, and you want to stream your images to it as well, cause, you know, you can.

Soon enough you’ll be like me, and have 12 different images covering 3 different environments, and you realize what a total PITA is it to manage all these darn things. Because officially Citrix says they don’t support moving that image to different hardware and if you try it you get the dreaded BSOD.

But if you’re me, you don’t accept that answer…

The only way Citrix supports moving your image from one set of hardware to another is to use XenConvert and P2V it back to bare metal, then take the drives out and slap them in the other hardware. I’ve done it, and it’s not pretty, but it DOES work.

I found a relatively cool way online to make my G6 image work on Hyper-V. It was actually pretty straightforward:

  1. Do your normal build process for your image on the G6 and set it to Private mode.
  2. Copy the vhd from your PVS server over the network to your Hyper-V machine. Create a new VM with multiple processors, an appropriate amount of ram, and attach the VHD to it as it’s hard drive.
  3. Very important.. remove the default NIC and add the “Legacy NIC”
  4. Boot your VM, log into the machine and let it install all the stuff it needs to work.
  5. Uninstall the PVS Target Device Software, reboot, reinstall it, then when it comes up make sure to tell it to use all of the NICs, even the ones it says are unavailable.
  6. You see, the problem with PVS is that it loads all the nic’s it’s bound to when it starts the GUI boot. If it doesn’t load the actual device (not just the driver), then you get your BSOD.
  7. So after you reinstall the software, reboot again.
  8. Run XenAppPrep.exe /pvs from the command line and shut down your machine.
  9. Go back to the file system and copy the VHD back over to the PVS data store, add it thru the console and you should be good to go to boot the image from either your original physical or to Hyper-V.

Great! You’re done, right?

Well, not so much. Wouldn’t you rather have your image be hardware-independent? Wouldn’t you like to boot it thru ESX?

This process doesn’t remotely work for ESX.

Oh, and didn’t I mention? This only works with 2008. If you want 2003 or anything earlier, good luck. There aren’t any drivers for the legacy NIC in Window 2003.

If you want hardware independence, read on for Part 2.