I'll try to answer your questions:
In the current Release you need the UCS DVS Client Software to authenticate against the Session Broker. In the backend we already use kerberized accounts, but the client communication is currently not cappable of full single sign on using an already authenticated account on the client (only SUSP: Same User Same Password). After a successful authentication against the Session Broker the account will also be used to communicate with the virtualized system (no further password prompt needed).
As any known user can be enabled to use an virtual desktop, I think your question aims at the administration of DVS?
The main administration tasks for DVS are available in the Univention Management Console webinterface (UMC). For each module you can give certain permissions to other users than "Domain Admins" by ACLs defined in the Univention Directory Manager (UDM).
This has not been done with the current release. While it might work under certain circumstances (if both the client and the virtualized desktop are windows and properly configured), the Session Broker Client doesn't support it. Please contact us directly if you want to discuss if this can be implemented in your installation.
The current virtualization stack of DVS doesn't provide any server side video enhancement or access to physical graphic cards. We are evaluating this for the upcomming release, but currently 3D is not supported.
Video and Audio acceleration is available for virtualized Windows Desktops, as it is a standard RDP feature provided by Windows 7 (depends on the version), so i.e. fullscreen HD video is possible,
This is possible for virtualized Windows Desktops, as RDP supports both Audio Playback and Recording. We strongly recommend to test it though, as the perfomance depends on both the version of your virtualzed Windows as on the RDP client.
Yes, this is also possible with virtualized Windows, depending on the features the Windows RDP service provides.
Low Level USB forwarding is not supported, the possibilities are once more defined by the chosen virtualized operating system and the client. Windows commonly supports "storage" forwarding (including USB storage), newer versions also support other devices like PTP or MTP.
The term "thin provisioning" is used with different meanings. UCS DVS offers "thin provisioning" for virtual machines: a new instance of a given virtual desktop image stores only the parts of its virtual blockdice on the given storage that differ from the original image.
UCS DVS makes sure that a user gets a virtual desktop once he is authenticated. If the server that hosted the users machine is down for any reason, the users machine will be started (or, if needed, newly instanciated) on a different host. The Session Broker is designed to be installed on two machines.
Further needs for HA can be integrated using the given scripting API.
No, we recommend to implement 3rd party tools (i.e. one of the certified software management tools).
It is no default feature, but can easily be done by a small script using the existing APIs. If once used machines are "destroyed" by a script, the next connection of a user will create a new instance.
There is some reporting in the Webinterface and one can access the Session Broker backend (SQL) for further statistics. But I wouldn't call it a "report system", though.
I'm not sure what you mean here. DVS is fully server side virtualization. If a client looses its connection, the running instance will be suspended after a connection timeout; once the user connects again he will be able to work where he lost the connection.
UCS DVS makes use of standard protocolls (mainly RDP and NX/X2Go) available on most platforms. Today, you'll need a Session Broker client to initiate the connection, which is a small python implementation. The Client is packaged for Linux and Windows yet, if you need it on other plattforms please contact us directly. I've heard about a Mac port but I'm unsure about its state.
We expect to be much more plattform-independent in the next release of UCS DVS, but that's not final yet.
The Session Broker needs an SQL backend, per default it is Postgres.
Hope it helps!