I'm not entirely sure what AD and a broker does in the whole game of connecting a user to his desktop. At this point, in our little test environment at work, we use a DNS name and an IP address to connect a user to his desktop. Afterwards eDirectory does the rest of the authentication. We have at this point 3 or 4 virtual desktops active. We provision some Windows desktops trough an ESX server.
Why would I need a broker and why would I need AD? Currently we can connect to our desktops without all this. This is of course a test environment of (in the near future) maximum 10 people.
In a smaller shop this makes complete sense.
However, let me give you my issue -- I've got 1200 students that need to connect to VDM's... I do not want to assign a virtual machine for each one -- it's very unlikely they'll all be on using a VM at the same time. So, I'd set up like -- max of 800 Desktops at once. A user fires up VDI client, they login using their campus-wide username and password, and see all the VM's available to them (CAD, Standard desktop, publishing desktop, so on) -- they pick, the broker finds an available VM for them and connects.
I don't want to assign each student a VM and then have to keep it powered on 24/7 for them. I create a standard image for the various types of systems they need. As they connect, VMware creates or powers on the appropriate VMs, and I move on with life.
In a small shop, create the VMs, hand out remote desktop profiles and move on with life. But when you have thousands of users that might need to use this system, it's pretty clear that's very difficult to do.
I don't agree with the AD-only implementation -- it'd be nice if it supported eDirectory (I use AD, so it's not a problem for me) -- maybe it does, I don't remember since I'm AD. However, it needs AD to be able to group users together to machine pools. For instance, I may have 1200 students, but only 300 of them are allowed to use the CAD machines. So, I put those 300 in a group in Active Directory, I tell VDM that the CAD group can use the CAD machine pool, and viola -- done. When a CAD student starts up the Virtual Desktop client, it says "Oh hey, you have the standard machine, the CAD machine and the publishing machine -- which do you need right now?" And off they go.
In a smaller shop this makes complete sense.
However, let me give you my issue -- I've got 1200 students that need to connect to VDM's... I do not want to assign a virtual machine for each one -- it's very unlikely they'll all be on using a VM at the same time. So, I'd set up like -- max of 800 Desktops at once. A user fires up VDI client, they login using their campus-wide username and password, and see all the VM's available to them (CAD, Standard desktop, publishing desktop, so on) -- they pick, the broker finds an available VM for them and connects.
I don't want to assign each student a VM and then have to keep it powered on 24/7 for them. I create a standard image for the various types of systems they need. As they connect, VMware creates or powers on the appropriate VMs, and I move on with life.
In a small shop, create the VMs, hand out remote desktop profiles and move on with life. But when you have thousands of users that might need to use this system, it's pretty clear that's very difficult to do.
I don't agree with the AD-only implementation -- it'd be nice if it supported eDirectory (I use AD, so it's not a problem for me) -- maybe it does, I don't remember since I'm AD. However, it needs AD to be able to group users together to machine pools. For instance, I may have 1200 students, but only 300 of them are allowed to use the CAD machines. So, I put those 300 in a group in Active Directory, I tell VDM that the CAD group can use the CAD machine pool, and viola -- done. When a CAD student starts up the Virtual Desktop client, it says "Oh hey, you have the standard machine, the CAD machine and the publishing machine -- which do you need right now?" And off they go.
Thanks for explaining that.
To answer your question:
No, you need AD to use VDI (XenDesktop needs it too). You can, however, make AD a "slave" (don't know the exact terminology) of your eDirectory structure and have AD copy all the permissions from eDirectory. That way, you can use eDirectory with VDI, but you'd have to have an AD server in between them.
