VMware Horizon Community
Rdiaz29
Enthusiast
Enthusiast
Jump to solution

Users unable to log into desktops

Hi,

We have a pool of thirty desktops where desktops gets deleted on power off. When desktops get spun up and become available, some don't allow users to log in . This is the error they get on the Windows 7 login screen after they enter their credentials: "The security database on the server does not have a computer account for this workstation trust relationship." If I log into the desktop locally (via console), I see the event ID 3210 which says: This computer could not authenticate with <DOMAINCONTROLLERNAME>, a Windows domain controller for domain <DOMAINNAME>, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same networking using the same name or the password for this computer account is not recognized. On the authenticating domain controller I see an event ID of 5722: The session setup from the computer <COMPUTERNAME> failed to authenticate. The name of the account referenced in the security database is <COMPUTERNAME>$. The following error occured: Access denied. According to this MS KB article (https://support.microsoft.com/en-us/help/810977/event-id-5722-is-logged-on-your-windows-server-based...), this can can occur if 1) An admin resets a computer account by using ADUC or another tool (which is not the case here) or 2) A new computer is joined to the domain using a name that already exists in the domain (which may be the case). I don't see any duplicate names anywhere: AD, DNS, DHCP, View Admin.

As a test, I disabled provisioning on the pool, deleted the desktops, and made sure that all AD computer objects, DHCP leases, DNS record, and Horizon Admin desktop entries were deleted. I also chose a naming scheme I have never used to avoid inconsistent View/Composer databases. I re-enabled provisioning and all desktops were provisioned with no problem. I performed this same run three times. On the third time, two desktops came up with the error above. I have verified that these problem desktops have an AD computer object and DNS record.

Has anyone ran into this problem?

Our setup:

-VMware Horizon View: 7.5.1

-vSphere: 6.5 U1

-Desktop OS: Windows 7 Ent SP1

-Forest level: Server 2008 (we have one Server 2016 DCs and some Server 2012 and 2008 DCs).

-Rob

1 Solution

Accepted Solutions
Rdiaz29
Enthusiast
Enthusiast
Jump to solution

The issue ended up being that our Windows 10 desktops were trying to connect to the DC using very high RPC Dynamic ports that were getting blocked by our firewall. Once we opened up the proper range of ports, this issue went away.

View solution in original post

6 Replies
techguy129
Expert
Expert
Jump to solution

Are you using the option to reuse a computer account on the pool? What happens if you disable it. The error is because the machine password doesn't match the AD Computer object. This could be for many reasons like failing to rejoin computer account to domain with an existing account. I would check out the View composer server logs and the logs on the guest VM (You'll need to connect to it with the local admin account)

Composer Logs

VMware Knowledge Base https://kb.vmware.com/s/article/1017939#Composer

Agent VM logs:

%system_drive%\Windows\Temp\VMware\vmware-viewcomposer-ga-new.log

Composer Server Logs:

C:\ProgramData\VMware\View Composer\Logs\

pastedImage_0.png

Reply
0 Kudos
Rdiaz29
Enthusiast
Enthusiast
Jump to solution

Hey techguy129,

I did try the pool with "Allow reuse pre-existing computer objects" unchecked. Still no luck. I did view the QuickPrep logs on the the offending desktops. They do join successfully and remove the initial machine password successfully. The View Composer Server logs didn't show me anything that was useful besides the creation of the desktop VMs themselves.

I decided to try Instant Clones since they use the ClonePrep process which is different that the QuickPrep process. The Instant Clone pool works perfectly all the time. I have migrated users over to this Instant Clone pool instead, but I would still like to know why we are having AD conflicts for desktops when using Linked Clones.

Reply
0 Kudos
Rdiaz29
Enthusiast
Enthusiast
Jump to solution

The issue ended up being that our Windows 10 desktops were trying to connect to the DC using very high RPC Dynamic ports that were getting blocked by our firewall. Once we opened up the proper range of ports, this issue went away.

FlorianFrank199
Contributor
Contributor
Jump to solution

Thanks!

We're stuck with the same issue at the moment. Do you have additional input regarding the type of traffic that were blocked by the firewall (so we can help our network team checking the logs)? Just to be sure: we're not talking about the Windows Firewall, right?

Thanks,

Florian

Reply
0 Kudos
Rdiaz29
Enthusiast
Enthusiast
Jump to solution

No, the issue was not the Windows firewall, and it most likely won't be since Windows allows all outbound traffic by default. We set up monitoring on our firewall and filtered based on the source IP subnet of our desktops. That's where we saw a lot of denies to the Domain Controllers for high RPC Dynamic Ports. We were only allowing a few ports in the 49,000 range. Active Directory has several TCP/UDP port requirements (see article here in the "Windows Server 2008 and later versions). We ended allowing all RPC dynamic ports from our desktop into our Domain Controllers: TCP 49152-65535.

Reply
0 Kudos
BenFB
Virtuoso
Virtuoso
Jump to solution

Alternatively you can configure a fixed range of RPC ports and only allow those.

Reply
0 Kudos