Archive for the ‘RDP’ tag
Nice whitepaper by VMware explaining why to choose VMware View over Microsoft RDS 2012. You can directly access the whitepaper using the link below.
A few month ago I wrote an article about using VMware View 3 with Novell eDirectory. At this time I was testing the installation with View 3, a Novell Netware eDirectory (not Open Enterprise Server) and a Active Directory Server which users and passwords were in sync through DirXML. As you see this environment has two gaps: It needs two directories and it uses a legacy Netware server which will not longer be supported in the future by Novell. Lots of Novell customers have already migrated their environment to OES (Open Enterprise Server) or will do so soon. With OES Novell introduced a service called DSfW (Domain Services for Windows) which emulates an Active Directory using a modified version of Samba and other components. For a Windows workstation the DSfW looks like a proper Active Directory and offers some interesting benefits like Clientless Login (without Novell Client), Cross-forest trust between eDirectory and Active Directory and Authentication to Active-Directory-style applications. In this article I’ll describe how to use VMware View with Novell OES and DSfW but please hold in mind that this is a non-supported configuration from VMware at this time. I’ve done the testing on VMware View 3 with RDP and Novell Open Enterprise Server 2.
First of all you’ll need a successful installation of Novell Open Enterprise Server 2 and additionally configured Domain Services for Windows. As the DSfW emulate an Actice Directory there shouldn’t be an issue to use them with View and the Virtual Center Server, but there is one. Please consider the Novell Knowledge Base TID 7004290 for further information. In a short form it says that VMware Virtual Center Server fails to authenticate with DSfW and also that happens with VMware View even this is not documented in the article. The reason here is that VMware requests a valid ticket for the service principal name (SPN). If the correct SPN isn’t returned the vCenter Server attempts the authentication using NTLM/SSP. By default DSfW does not create a SPN with “ldap/<ip address of the DSfW DC>. However if you configure the SPN it works. To create the SPN edit the Domain Controller object using iManager or ConsoleOne. The DC object is the name of the DSfW server and is present in “ou=domain controllers,<dc=…>”. Change to the other tab and edit the servicePrincipalName attribute. Please add the ldap/<ipaddress> attribute value on the servicePrincipalName attribute. After that you’ll need to restart the DSfW services using the command “xadcntrl reload”.
The DSfW is not correctly configured and you can now add the Windows Server 2003 to the DSfW domain and start the installation of the View Connection Server afterwards. You shouldn’t see any issue through the installation. To get more information on how to configure DSfW for using login scripts, network shares and so on please check the Novell DSfW documentation. If you still want to use the Novell Client please check my other article for the correct setup with the View Agent.
As you see it’s quite easy to setup VMware View with DSfW but I need to say it again that this is a not supported configuration.
Since Virtual Desktop Manager 2.1 the VMware Virtual Desktop Infrastructure got a default setting which blocks direct RDP connections to the virtual desktops. When a user tries to connect to the desktop with a standard Microsoft RDP client he will get a message stating: Access denied. In case that there was a requirement for connections from non-View/VDM clients the administartor needed to change a registry parameter to enable the access.
The users in a View environment access the virtual desktop via the RDP protocol. For that to work the user needs to have special access rights. As a standard only the administrator has direct RDP access to the remote system. To configure access for the user you could do that on a per desktop basis manually what would be time consuming or you can use the Group Policy Objects within the Active Directory which is the recommended way. First of all you’ll need to figure out who should get remote access and create one or more user groups in the Active Directory. In this example the groups is called vditestusers and it’s a member of the domain TEST. Diese This group will be a member of the local group Remote Desktop Users on the virtual desktop which has the needed remote access rights. For that reason you’ll need to configure the group in the GPO’s as a Restricted Group.
After that add configure the group as a member of the local group Remote Desktop users and the users will have remote access.
In the last step you need to allow the users to connect remotly using the Terminal Services. There is an option within the administrative templates to do that. Just go to: Computer Configuration, Administrative Templates, Windows Components and then Terminal Services. This option will enable the Remote Access on the desktop operating system.
VMware XP Deployment Guide (Seite 4): http://www.vmware.com/files/pdf/XP_guide_vdi.pdf
Restricted Groups: http://technet.microsoft.com/en-us/library/cc785631.aspx
Centrally enable Remote Desktop using Group Policy: http://technet.microsoft.com/en-us/library/cc776790.aspx