WebGeeksUnlimited
asked on
SBS2011 Standard RDS Problem
I’ve attached a new Win7 Pro x64 desktop to our SBS2011 server and assigned the computer to one of our users. This will replace his old desktop I hope later today or tomorrow.
When you sign in as this user into RWA, the computer shows up on the computers list that he can access. When using IE, you click connect, the ActiveX loads up and then prompts for the user name and password in the “Remote Desktop Connect” dialog that appears.
The problem is, it keeps prompting for the user name and password, which I know is correct.
I checked the desktop, the user is in the “remote desktop users” group as well as in AD. In the Computer properties, the user is listed as “Remote Desktop” users. It doesn’t even accept the administrator account and any other admin account either. This is all being done on the local network.
But directly from the SBS2011, I can right click the computer and RDS into it OK or even do remote assistance OK, but I can’t RDS in from the RWA page.
What am I missing here?
When you sign in as this user into RWA, the computer shows up on the computers list that he can access. When using IE, you click connect, the ActiveX loads up and then prompts for the user name and password in the “Remote Desktop Connect” dialog that appears.
The problem is, it keeps prompting for the user name and password, which I know is correct.
I checked the desktop, the user is in the “remote desktop users” group as well as in AD. In the Computer properties, the user is listed as “Remote Desktop” users. It doesn’t even accept the administrator account and any other admin account either. This is all being done on the local network.
But directly from the SBS2011, I can right click the computer and RDS into it OK or even do remote assistance OK, but I can’t RDS in from the RWA page.
What am I missing here?
Larry Struckmeyer MVP
Sorry to be so "elementary", but can you verify that the user and the computer were added with the SBS sanctioned wizards, and that users are in the My Business Users SBS Users, and computers in the corresponding computers OU?
ASKER
The computer is in the SBSComputers OU, but the user account is located else where as migrated over from SBS2003. Does it need to be in the SBSUsers to work properly?
For example;
USER is located in "domain.local | Corporate | Organisation | Users"
Desktop is located in "domain.local | My Business | Computers | SBSComputers"
So does it make a difference then that they are not located in "domain.local | My Business | Users | SBSUsers"?
That would seem a bit limiting if so.
For example;
USER is located in "domain.local | Corporate | Organisation | Users"
Desktop is located in "domain.local | My Business | Computers | SBSComputers"
So does it make a difference then that they are not located in "domain.local | My Business | Users | SBSUsers"?
That would seem a bit limiting if so.
Yes, unless you make a whole lot of modifications.
Move the users to the appropriate OU then in the SBS console go to the users and groups section and locate "change user roles". Run the wizard and on the page where you add the users select display all users in active directory, then complete the wizard. This will assign the users the appropriate permissions and much more.
The connecting client machine also has to have the SBS self signed certificate installed unless you have purchased and installed a 3rd party certificate on the server.
Move the users to the appropriate OU then in the SBS console go to the users and groups section and locate "change user roles". Run the wizard and on the page where you add the users select display all users in active directory, then complete the wizard. This will assign the users the appropriate permissions and much more.
The connecting client machine also has to have the SBS self signed certificate installed unless you have purchased and installed a 3rd party certificate on the server.
Yes, otherwise it will not show up in the SBS Console. Lots of policies are controled by the GPO's that are applied by OU. Put the user in SBSUsers and try your connection. This may not be the only issue, but it is certainly one.
Was this a migration? That is the usual way we find users not in the right OU, but if you created users in ADUC you can have the same results. SBS should be managed by the wizards.
Was this a migration? That is the usual way we find users not in the right OU, but if you created users in ADUC you can have the same results. SBS should be managed by the wizards.
ASKER
Yes. this was a migration from SBS2003 to SBS2011.
I tried moving the user to the SBSUsers and tried again, ran into the same issue with trying to connect with RDS. I haven't thought about the the SSL certificate, it's possible that maybe be an issue, but also have a 3rd party cert installed. Ran into a another issue earlier related to the certs, maybe this is is related.
I tried moving the user to the SBSUsers and tried again, ran into the same issue with trying to connect with RDS. I haven't thought about the the SSL certificate, it's possible that maybe be an issue, but also have a 3rd party cert installed. Ran into a another issue earlier related to the certs, maybe this is is related.
If using a GoDaddy cert make sure the intermediates were installed before the actual cert.
Philip
Philip
Simply moving them to the other OU will not apply the appropriate permissions. After you do the migration as mentioned above you need to apply a user role to the users. Specifically; go to SBS console | users and groups | users | change user role for user accounts (lower right) | select role - replace/add user permissions | check display all users in active directory | add the users to which you want to apply the role | and finish.
You then have to look at the properties of each user and under computer select a computer and check "can remotely access this computer", or you can do the latter part from the computers section of the console and add the user.
You then have to look at the properties of each user and under computer select a computer and check "can remotely access this computer", or you can do the latter part from the computers section of the console and add the user.
ASKER
The SSL cert being used was issued by Entrust, but after some further investigation, that does not appear to be an issue.
The user does have the "can remotely access this computer" checked and from what I see, there does not seem to be anything missing as far as groups/roles.
Could there be an issue with the SBS2011 TS Gateway?
From the SBS2011 server I can RDP to the desktop no problem ... but when using the RWA page where they have an option to connect, there seems to lay the problem.
The user does have the "can remotely access this computer" checked and from what I see, there does not seem to be anything missing as far as groups/roles.
Could there be an issue with the SBS2011 TS Gateway?
From the SBS2011 server I can RDP to the desktop no problem ... but when using the RWA page where they have an option to connect, there seems to lay the problem.
>>"Could there be an issue with the SBS2011 TS Gateway?"
It can be. Can you connect to the SBS itself? If so it is probably OK and the certificate is fine.
Did you run the change user role and give the user rights to access the PC through RWW/RWA using the steps I provided? The console governs RWW/RWA access.
It can be. Can you connect to the SBS itself? If so it is probably OK and the certificate is fine.
Did you run the change user role and give the user rights to access the PC through RWW/RWA using the steps I provided? The console governs RWW/RWA access.
ASKER
Through RWA, I can't seem to access anything ... but can directly RDP to the SBS or desktop.
I checked the RemoteAccess.log and see an exception regarding the SSL certificate.
It seems RWA is using the wrong URL and as a result, the SSL cert does not match.
The server supports multiple domains and the SSL cert from Entrust has two particular domains setup for OWA and ActiveSync operation. But it appears that despite that fact you connect to RWA using the proper URL which is tied to a valid SSL cert, when you click the connect to RDP to the desktop or server, it is using the default URL to invoke the sesssion. Of course then the SSL cert does not match.
I recall in the SBS a couple places to set the default URLs for various things and I suspect what it's using for TS us still set on the default. Now I have to remeber where that was to check them out.
I checked the RemoteAccess.log and see an exception regarding the SSL certificate.
It seems RWA is using the wrong URL and as a result, the SSL cert does not match.
The server supports multiple domains and the SSL cert from Entrust has two particular domains setup for OWA and ActiveSync operation. But it appears that despite that fact you connect to RWA using the proper URL which is tied to a valid SSL cert, when you click the connect to RDP to the desktop or server, it is using the default URL to invoke the sesssion. Of course then the SSL cert does not match.
I recall in the SBS a couple places to set the default URLs for various things and I suspect what it's using for TS us still set on the default. Now I have to remeber where that was to check them out.
The appropriate URL is set up within the "configure your internet address" wizard in step 7. It defaults to remote.yourdomain.abc unless you select "advanced settings".
(for SBS 2008 but similar with SBS 2011)
http://blogs.technet.com/b/sbs/archive/2008/10/15/introducing-the-internet-address-management-wizard-part-1-of-3.aspx
The FQDN within the wizard, the certificate, and the name with which you connect to the server (public DNS host record) must all match.
(for SBS 2008 but similar with SBS 2011)
http://blogs.technet.com/b/sbs/archive/2008/10/15/introducing-the-internet-address-management-wizard-part-1-of-3.aspx
The FQDN within the wizard, the certificate, and the name with which you connect to the server (public DNS host record) must all match.
You have forwarded 443 if you can get to the RWW page, but have you also forwarded port 987 ? (it was 4125 with SBS 2003)
ASKER
OK, I recall step 7 and it did setup remote.defaultdomain.com as the default.
But our SSL cert which was setup for OWA and ActiveSync cover;
webmail.domain1.com
webmail.domain2.com
all of which are in a single SSL cert.
With the EMC, the various URLs have been changed to match the proper SSL certificate, so that is all working just fine.
So it seems because RWA is using remote.defaultdomain.com when you click connect, hence the mismatch.
Is there a way to configure the RWA so that it uses webmail.domain1.com instead of remote.defaultdomain.com some place? Worse case, I may need to have remote.defaultdomain.com added to the SSL cert and have it reissued.
But our SSL cert which was setup for OWA and ActiveSync cover;
webmail.domain1.com
webmail.domain2.com
all of which are in a single SSL cert.
With the EMC, the various URLs have been changed to match the proper SSL certificate, so that is all working just fine.
So it seems because RWA is using remote.defaultdomain.com when you click connect, hence the mismatch.
Is there a way to configure the RWA so that it uses webmail.domain1.com instead of remote.defaultdomain.com some place? Worse case, I may need to have remote.defaultdomain.com added to the SSL cert and have it reissued.
ASKER
Note: Of course those are not the actually domains above, just examples.
You can to re-run the wizard and set it to webmail.domain1.com
Having said that I am surprised you can get to the RWW page.
To confirm my last comment, you did forward port 987?
Having said that I am surprised you can get to the RWW page.
To confirm my last comment, you did forward port 987?
ASKER
I call up the RWW page using webmail.domain1.com/remote
I just tried pulling it up with remote.defaultdomain.com and you get the cert warning, but you can still pull it up OK.
Now oddly enough, I click the connect button and enter the login and it goes farther until it says the cert mismatches and disconencts.
But using the webmail.domain1.com, no cert complaint, but keeps prompting for the user id and password. This seems like it may be something beyond the cert???
As for port 987, you are referring to forwarding in the firewall. I have not done this yet as I am only testing this on the LAN at this point. The firewall on the SBS is turned off, so it's not a factor.
I just tried pulling it up with remote.defaultdomain.com and you get the cert warning, but you can still pull it up OK.
Now oddly enough, I click the connect button and enter the login and it goes farther until it says the cert mismatches and disconencts.
But using the webmail.domain1.com, no cert complaint, but keeps prompting for the user id and password. This seems like it may be something beyond the cert???
As for port 987, you are referring to forwarding in the firewall. I have not done this yet as I am only testing this on the LAN at this point. The firewall on the SBS is turned off, so it's not a factor.
I think you will have to change the name within the wizard. OK on the firewall/port.
ASKER
One question then, as this server is already live, if I do that wizard step again, it won't mess up anything exisiting except change the default domain ... right?
ASKER
I found something that mentioned that RPC doesn't have "Windows Authentication" enabled and prevents that from working. So I thought worth a try and enabled it on the RPC leg.
Now I get a different error and it doesn't keep prompting me for credentials.
It now says that it can't connect because no certificate was configured to use at the terminal services gateway ...
Now where is that configured?
Now I get a different error and it doesn't keep prompting me for credentials.
It now says that it can't connect because no certificate was configured to use at the terminal services gateway ...
Now where is that configured?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
OK, I ran the wizard and fixed the name from the remote.defaultdomain.com to the one assigned to the Entrust SSL cert being webmail.domain1.com.
Then I had to go into IIS and tie the Entrust SSL cert back on all the HTTPS bindings.
Last but not least, under the default site, select the RPC folder, enable the "Windows Authentication" and it all started to work.
This appears to be disabled by default, but must be enabled for TS to work as if it's disabled, it won't work.
But, even though I've gone into IIS and enabled that authentication method, after a short bit, it ends up disabled again. So it appears that Group Policy is playing a game with me and disabling it again or at least that what I assume.
If I can fix what ever is overriding this now, this will stay working ... I appreciate the help you have provided Rob :)
Then I had to go into IIS and tie the Entrust SSL cert back on all the HTTPS bindings.
Last but not least, under the default site, select the RPC folder, enable the "Windows Authentication" and it all started to work.
This appears to be disabled by default, but must be enabled for TS to work as if it's disabled, it won't work.
But, even though I've gone into IIS and enabled that authentication method, after a short bit, it ends up disabled again. So it appears that Group Policy is playing a game with me and disabling it again or at least that what I assume.
If I can fix what ever is overriding this now, this will stay working ... I appreciate the help you have provided Rob :)
If the certificate was imported using the wizard: SBS console | Network | connectivity | add a trusted certificate, there should be no need to make any IIS changes, at least not for the default connection.
SBS = wizards, wizards, wizards :-)
SBS = wizards, wizards, wizards :-)
You must use the same URL/URI to access _all_ remote features on SBS.
* OWA
* Outlook Anywhere (RPC/HTTPS)
* RWA
The wizards should be used to configure the remote.domain.com URL for all services and then the Third Party Trusted Certificate wizard to create the CSR and then to import the certificate.
The TPC wizard sets the certificate in the appropriate places along with the necessary permissions set.
Run the Internet Address Wizard and set the remote.domain.com (or whatever URL = SSL)
Run the TPTC wizard and select "Use Cert Already Installed" option.
Philip
Philip
* OWA
* Outlook Anywhere (RPC/HTTPS)
* RWA
The wizards should be used to configure the remote.domain.com URL for all services and then the Third Party Trusted Certificate wizard to create the CSR and then to import the certificate.
The TPC wizard sets the certificate in the appropriate places along with the necessary permissions set.
Run the Internet Address Wizard and set the remote.domain.com (or whatever URL = SSL)
Run the TPTC wizard and select "Use Cert Already Installed" option.
Philip
Philip
"Last but not least, under the default site, select the RPC folder, enable the "Windows Authentication" and it all started to work. "
You're probably correct with this all along, on several SBS2011's I've had to re-enable this as Exchange is pre-installed seems to only set itself to Basic Auth, run the powershell command in the exchange management shell to set it permanently.
get-outlookanywhere | set-outlookanywhere -IISAuthenticationMethods:
-Edit, I've just noticed the date on this post, whoops!
You're probably correct with this all along, on several SBS2011's I've had to re-enable this as Exchange is pre-installed seems to only set itself to Basic Auth, run the powershell command in the exchange management shell to set it permanently.
get-outlookanywhere | set-outlookanywhere -IISAuthenticationMethods:
-Edit, I've just noticed the date on this post, whoops!