Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Could be the cert warning is normal, I think I may have just checked trust. Here is a screen shot. To me it screams somethings up with the ldap authentication since both this and the ASA started failing.
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.
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.
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.
There is no value there, what value should be there the internal name for the RD gateway or the external?
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?
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.
The only log i see with any activity is here %SystemRoot%\System32\Wine
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?
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.
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...." ??
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
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
What's with all of the Deny policies?
We set up a dedicated security group for RDS access since everyone is a member of Domain users and not all folks may need access. Doing this also makes a license audit go smoother.
We set up two resource policies:
Admins + RDS Users --> Domain Computers
Admins --> Domain Controllers
We don't make any further changes.
We set up a dedicated security group for RDS access since everyone is a member of Domain users and not all folks may need access. Doing this also makes a license audit go smoother.
We set up two resource policies:
Admins + RDS Users --> Domain Computers
Admins --> Domain Controllers
We don't make any further changes.
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).
Premium Content
You need an Expert Office subscription to comment.Start Free Trial