I have found some additional information for users experiencing the error noted in the title regarding VMWare View "Failed to Join Domain" errors in View 5.0. Besides the fix noted in the link below, I found that customers that have sub domains will need to ensure the proper DNS servers are setup and used in the DHCP scope for the VDI Desktops. If you use the primary parent domain, but the desktops live in the sub-domain, YOU MUST USE DNS Servers in the sub-domain, not the parent domain. I also recommend using a DHCP scope in the sub-domain as well. The main problem is timing between adding computers to the AD and traversing down to the sub-domain from the parent domain controllers.
http://dharmgolf.blogspot.com/2011/11/vmware-view-50-fix-for-windows-7.htmlAlso, ensure the DHCP server is setup with the following settings:
Good luck..
I think we have the same issues. View-agent works fine with agent version 4.6.1 but not with 5.0.
ReplyDeleteThe clients uses the same DNS-servers as the rest of the View-infastructure but their connection specific dns-suffixes differ. The View client are have this suffix dhcp.region.company.net and the servers for View are using the suffix location.company.net so the only thing in common is the company.net part. I think this will be a case to VMware since it works with 4.6.0 and 4.6.1 but not with 5.0.
I agree. I think VMWare actually fixed some issues around authentication and security between sub-domains and parent domains. I also found some networking issues on a 3com switch as described below that was blocking MAC changes from specific sources. VMWare fails with genereic messages that can lead you down various paths. I am going to blog about that soon, since there is sometimes problems with the underlying infrastructure that VMWare reports and masks the real issues.
ReplyDeleteMultiple source links to 3com from server infrastructure causes MAC/ARP tables to block vswitch traffic, thus VMWare View reports bugus errors:
"The final root cause turned out to be related to a configured feature on the 3Com 8800 intended to prevent MAC spoofing via gratuitous ARPs. This feature was in fact undocumented in the 8800's command reference manuals, but was found relatively well documented for some other models of 3Com switches. The specific configuration command was "arp entry-check fixed-all", which is a global command that locks IP, MAC, and interface relationships together and prevents any moving of MAC addresses between interfaces or changes in the MAC addresses associated with IP addresses in the system ARP table. This feature was configurable on a global basis only, and could not be turned off/on for specific interfaces as is possible for some other vendor's products. With the ARP entries locked to the first learned interface, any moving of VM guest systems between 10 Gig trunks resulted in them being unable to communicate.
An alternative command, "arp entry-check fixed-mac", was used, which still prohibits any changes to learned relationships between IP addresses and MAC addresses (preventing MAC spoofing attacks) but allows MAC addresses to move from interface to interface as Ethernet frames sourced from MAC addresses are seen on different interfaces. This allowed vswitch to move guest systems between the 10 Gig interfaces for load balancing as needed, and restored expected and required system functionality."