bhieb
asked on
RemoteApps not working after DC migration
Ok so over this week I removed my last 2008 DC and moved to 2012 R2, everything went as planned no errors or anything. However today my remote users aren't able to access their published RemoteApps. They can browse to the gateway authenticate fine and see their apps, but when they try to open them 2 odd things happened. It times out and prompts them for their user, then just keeps doing that to no avail.
2 other clues as to what it may be. They also get a prompt to trust the certificate, which they shouldn't as the rds deployment uses a properly signed one, and this had been working fine for 6 months now. The other oddity is my CiscoAnyConnect won't authenticate to the LDAP properly either. If i add them as a AAA local user they can vpn then they can log in, but they've never had to VPN to access this before the DC change.
Any ideas?
2 other clues as to what it may be. They also get a prompt to trust the certificate, which they shouldn't as the rds deployment uses a properly signed one, and this had been working fine for 6 months now. The other oddity is my CiscoAnyConnect won't authenticate to the LDAP properly either. If i add them as a AAA local user they can vpn then they can log in, but they've never had to VPN to access this before the DC change.
Any ideas?
ASKER
I think I might be narrowing in on it. I fixed the VPN issue. The other thing I did this week was to move the built in domain admin account (administrator) to its own OU. That is what broke AnyConnect as the ldap connection string didn't have the right OU.
Is there something in RDS that would care as well? I can't imagine so. FYI I've tried with and without the firewall on, and no luck. Also looked at the asa logs and that all seems normal. Something in the RDS deployment is just not aware of the new DC stuff and/or the administrator move.
Is there something in RDS that would care as well? I can't imagine so. FYI I've tried with and without the firewall on, and no luck. Also looked at the asa logs and that all seems normal. Something in the RDS deployment is just not aware of the new DC stuff and/or the administrator move.
DNS 0 and 1 on the RDS Broker/Gateway/RDWeb/RD Session Host(s) are pointing to the new DC/DNS servers?
IPConfig /FlushDNS from an elevated command prompt on all RDS systems after verifying they are pointing to the correct DNS servers.
IPConfig /FlushDNS from an elevated command prompt on all RDS systems after verifying they are pointing to the correct DNS servers.
Also check Remote Desktop Licensing.
Moving the built in Administrator account is not a good idea, and you should use a specific ldap account for LDAP, NOT the administrator account.
Moving the built in Administrator account is not a good idea, and you should use a specific ldap account for LDAP, NOT the administrator account.
ASKER
Philip, No luck even went as far as restarting the License, gateway, broker and session servers after the flush on all 3. The really weird part to me is that it authenticates fine to list their work resources, it is only when they launch them that it fails.
Peter, I did change the ldap user when i fixed the ASA, plus ldap shouldn't be the issue with RDS. As far as to move it or not, I've read conflicting posts, of course MS says you should disable it and never use it unless it is a disaster recovery scenario (as well as frankly a bunch of GPO stuff to be sure it can't be used). https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d--securing-built-in-administrator-accounts-in-active-directory
Since I'm a one man shop I've used it more than I should and that was already on my road map to rectify this year.
Peter, I did change the ldap user when i fixed the ASA, plus ldap shouldn't be the issue with RDS. As far as to move it or not, I've read conflicting posts, of course MS says you should disable it and never use it unless it is a disaster recovery scenario (as well as frankly a bunch of GPO stuff to be sure it can't be used). https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d--securing-built-in-administrator-accounts-in-active-directory
Since I'm a one man shop I've used it more than I should and that was already on my road map to rectify this year.
ASKER
The other odd part is that it does work IF they VPN first, that wasn't the behavior before the DC upgrade. Part of my goal with moving to RemoteApps was to eliminate the need for VPN and secure it using RDS.
Also just to be sure I moved the Administrator account back restarted the servers still no luck.
Also just to be sure I moved the Administrator account back restarted the servers still no luck.
Are you using Single Sign-On (SSO) in Group Policy? Did the Group Policy setup get modified or tweaked somehow during the DC migration?
Make sure the IIS setting for DefaultTSGateway is set on the broker.
Make sure the IIS setting for DefaultTSGateway is set on the broker.
ASKER
There is no value there, what value should be there the internal name for the RD gateway or the external?
ASKER
no SSO
It should be remote.domain.com that users will connect to both externally and internally.
Set up the remote.domain.com in DNS and set the IP to the broker. That allows users to connect internally and externally.
If internal users are using RemoteApps then set up SSO. Why have them authenticate when they don't have to?
Set up the remote.domain.com in DNS and set the IP to the broker. That allows users to connect internally and externally.
If internal users are using RemoteApps then set up SSO. Why have them authenticate when they don't have to?
ASKER
I tried both internal and external, no luck. As well as IP and name for the server they are connecting to. I haven't deployed to internal yet as they usually just have a full install of the app so SSO hasn't been needed yet.
Look for the RDS specific Event Logs on the Broker. What do they say? There should be some specific errors or warnings.
ASKER
The only log i see with any activity is here %SystemRoot%\System32\Wine
Check the Session Hosts' logs.
ASKER
yah just finished doing that and the client logs, nothing.
The initial prompt looks normal.
Is there a Group Policy setting in place to force the Session Hosts to prompt for passwords always?
We've dealt with dropped RemoteApp problems in the past. Some were due to network routing issues like improper IIS setting (DefaultTSGateway), DNS not configured correctly. Gateway on the RDS server's NIC set incorrectly, and sometimes a misbehaving DC.
Is Replication on the DCs working as expected? FSMO Roles are where they belong and recognized by all DCs on the domain?
Is there a Group Policy setting in place to force the Session Hosts to prompt for passwords always?
We've dealt with dropped RemoteApp problems in the past. Some were due to network routing issues like improper IIS setting (DefaultTSGateway), DNS not configured correctly. Gateway on the RDS server's NIC set incorrectly, and sometimes a misbehaving DC.
Is Replication on the DCs working as expected? FSMO Roles are where they belong and recognized by all DCs on the domain?
ASKER
No RDS specific policies, the servers are all in one OU the only policy is the disable shutdown tracker.
I agree that it is likely the change in DC that messed this up, although it is likely not the dc itself rather some rds deployment component still looking for the old dc's.
Replication status tool is all clear and the FSMO rules where all transferred and reporting correctly as DC1. Netdom query dc and netdom query fsmo all look good. repadmin /showrepl is all clear too.
I agree that it is likely the change in DC that messed this up, although it is likely not the dc itself rather some rds deployment component still looking for the old dc's.
Replication status tool is all clear and the FSMO rules where all transferred and reporting correctly as DC1. Netdom query dc and netdom query fsmo all look good. repadmin /showrepl is all clear too.
ASKER
What really has me scratching my head is why it works when the VPN is connected. It has to be something in the gateway or broker.
Are the remote users on windows 10 1709 ??
Does it work if you uncheck printers under "Allow the remote computer to access the following...." ??
Does it work if you uncheck printers under "Allow the remote computer to access the following...." ??
ASKER
Nope, windows 7, and no luck with no printers option either.
Do they have the updated RDP version 8,1 ??
https://support.microsoft.com/en-us/help/2923545/update-for-rdp-8-1-is-available-for-windows-7-sp1
https://support.microsoft.com/en-us/help/2923545/update-for-rdp-8-1-is-available-for-windows-7-sp1
Three things:
1: Open Network Policy Server/Services on Broker: Right click root node and Register in AD
2: Check Resource Access Policies to make sure things are correct
3: Check Computer Access Policies to make sure things are correct
1: Open Network Policy Server/Services on Broker: Right click root node and Register in AD
2: Check Resource Access Policies to make sure things are correct
3: Check Computer Access Policies to make sure things are correct
ASKER
We might be getting somewhere Philip, I've never had a reason to open those settings. I did re-register it, and rebooted it. But still no luck.
Regarding 2 and 3 what would be considered "correct" , I've uploaded some screenshots.
1Capture.PNG
2Capture.PNG
3Capture.PNG
4Capture.PNG
Regarding 2 and 3 what would be considered "correct" , I've uploaded some screenshots.
1Capture.PNG
2Capture.PNG
3Capture.PNG
4Capture.PNG
ASKER
I'm out for the weekend, I'll catch base back here Monday.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've never even been in these pages so anything in here likely came from when I deployed the RDS roles via the 2012 wizard thing.
I do a similar thing, but not at this level at the license server I have RDS groups setup. then I further group limit it via the app deployments. so although it looks like all domain users could access the gateway they'd have no access to resources unless they were in the right group(s).
I do a similar thing, but not at this level at the license server I have RDS groups setup. then I further group limit it via the app deployments. so although it looks like all domain users could access the gateway they'd have no access to resources unless they were in the right group(s).
ASKER
No solution fixed the issue, but I've moved on. Needing a VPN connection to work, is not a big deal and adds a layer of security.
ASKER