mmthomas

Here is a registry hack to try. I don't know if it will help in your situation or not, but it has been known to fix some terminal services logon issues in both 2008 and 2003 server. As always with registry stuff, back up your registry first. 1. Click Start, click Run, type regedit in the Open box, and then click OK. 2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server 3. Click Edit, point to New, and then click DWORD Value. 4. In the New Value #1 box, type IgnoreRegUserConfigErrors, and then press ENTER. 5. Right-click IgnoreRegUserConfigErrors, and then click Modify. 6. In the Value data box, type 1, click Decimal, and then click OK. 7. Exit Registry Editor.

Hmm, odd. In the group policy, in the same area as the "allow log on through terminal services" there is also a "Deny log on through terminal services." That isn't set to deny anything is it? Also, is there an error message being logged now when a user is denied access?

What are the IP addresses on the Linksys router and the 2wire router? Are you forwarding through both?

Is there anything in your event logs when this happens? My first suspicion would be a failing NIC on the server or the server's port on the switch locking up. Is there anything in your logs about the NIC or about the network connection dropping?

Check this link for that error.

You need to do this in group policy; the default domain controller policy >> Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Be careful not to delete what is already there or you can remove the ability of administrators to remote to the machine.

Do you have a dns record through GoDaddy that goes directly to my.ip.123.456 without the /ts? If not, I would try making one with through GoDaddy with a name like ts.mydomain.com. Then put that in the Connect To box. I think the /ts may be causing problems in the connect to process. I know on my TS, if I put in servername/ts then it will tell me that it can't connect to that server, but works fine with just servername. edit: You can test this before making a dns change by putting the info in your workstation's hosts file and seeing if it works.

I may have missed or misunderstood this sentence in your original post as well. Do you have another domain name that mydomain.com is being forwarded to? If so, what happens when you put that server and domain name in the Connect to box?

Hi, Pred. Welcome to the forum.

Okay, I've gone through setting up ts web access on a virtual server just to see it fresh and think I've probably led you through more than we needed to do. At this point, why don't you go ahead and set the primary dns on your server back to what it was originally set to, 208.109.188.8, and let's look at this afresh. Let me make sure that I understand what you are doing, too. 1) You have one hosted virtual server that is running terminal services and TS Web Access. 2) You and users access that server by going to http://www.mydomain.com/ts. This works and you get to the TS Web Access site. 3) When you click the Remote Desktop button and put www.mydomain.com in the Connect to: box and click Connect, you get a certificate error. 4) When you click Yes to connect despite the error, you get a login box. Attempts to login fail. 5) If in step 3 you put in the IP address rather than www.mydomain.com logging in works. Is that a correct summary so far?

I don't know how complex your network/domain is, but under Administrative Tools you would open Group Policy Management if you are in a Windows domain. If your server is just a stand-alone server that is not part of a Windows domain, then the Local Security Policy will be all that you have access to. If that's the case, then the options are probably disabled because you cannot enforce client machine behavior if the clients and server are not domain members. But if you are in a Windows domain, then opening Group Policy Management gives you access to all of the policies in the domain (assuming you have permissions). If you have a big network, there could be a lot of these. You would need to check which policies apply to your server. Another way to check is to run gpresult.exe from a command line or rsop.msc from the Run box. That should tell you what policies are being applied to your server. Note that they can also be run on clients, too.

No, that won't work. 255.255.255.255 is a broadcast address, so again the server will be sending your connection off into the ether rather than processing it itself. Try using 127.0.0.1 there as well. You shouldn't be typing 'mydomain.com' but rather the whole fqdn for your server, which I think you said earlier was 'www.mydomain.com'. If we're still having problems setting up dns on your server, it may be faster to remove the DNS role and find another DNS server that resolves your host properly. There obviously are some as you can connect to the terminal server from your remote client machines.

Okay, that's good info and shows what is probably the problem. When you are putting in www.mydomain.com into the TS window, the server is sending it off to that IP address instead of processing it locally. First, add the host record in DNS on your server for www.mydomain.com. This page shows how to do on an earlier operating system, but it hasn't really changed in Windows 2008. Then in the TCP/IP properties where it shows the two DNS servers, change the primary DNS Server to 127.0.0.1 -- that's means to look at itself for the IP address. After making those changes, try the nslookup again.

Unfortunately, it's hard to say for sure, but probably has to do with how GoDaddy runs its hosted server farm. It is likely that they are doing some load-balancing and forwarding which is what causes the ping addresses to be weird. You can see similar results from other large entities like Google and Amazon. For pinging directly to your IP address, they may have a firewall or filter to block ping by default. Sadly, these make diagnosing network issues difficult. You may be able to ask them if they can allow pings to your public IP address, at least for diagnostic purposes until you get your site up and running.

That sounds ok so far. You will need to check and make sure that the server is setup to point to itself as the DNS server now that you have added that role. Then you will also need to add a New Host record in the forward lookup zone for www.mydomain.com with the public IP address that you're using.

Okay, it sounds like the question may be, then, whether your server is setup to point to anything for DNS. Go to your server's control panel >> Network and Sharing Center >> Network Connections and go into the Properties of the Local Area Connection then highlight the TCP/IPv4 line and click the Properties button. What does it list for DNS servers? If there is nothing listed for a DNS server, you can put in 4.2.2.1. That's a public DNS server hosted by Level 3 Communications and should work. Another way to check that is to go to a command prompt and type "nslookup". It should tell you what the default server is. You can then type www.mytestdomain.com at the prompt and if DNS is working it should return the IP address. You may want to run the nslookup first, then if there is no default server, check the TCP/IP settings and add the DNS server if there isn't one, and then go back to nslookup and check again. If nslookup is resolving the address and there are DNS servers configured but the TS page still won't accept the hostname, then there is a different problem.

No problem. Computers use DNS (domain name system) to resolve host names to IP addresses. When you setup the TCP/IP properties for a network connection, you either specify the DNS server statically, or you set up your DHCP server to give out the DNS server address when it hands out host IP addresses. So, when you type, for example, www.google.com in your browser, your computer sends a query to whatever DNS server it is pointed to and asks what the IP address is. If that DNS server doesn't know, it will usually forward the request up a root DNS server or other server to try to resolve the address. If your computer receives an IP address in response, then it goes ahead and forward the request for the google web page off to that IP address. If it gets no IP address, you get the server cannot be found error in your browser. Thus, when you say that putting the IP address in the terminal server page works, but using the hostname doesn't, it makes me suspect a DNS lookup problem. Now, you say that putting in www.mydomain.com works for external users to get to your terminal server which should be true as you say that you have registered your domain and that host with your provider. So external look up are fine. But when you put the hostname in the terminal server box, that is where it fails. So the terminal server is not connecting the hostname with the IP address. So, the question now is how is your terminal server set up for DNS. If you have a Windows active directory domain structure, then you will have at least one internal server that is running DNS. You can't setup a Windows domain controller without one. So if you have a Windows domain, then your terminal server is probably pointing at your internal DNS server. Now, this wouldn't cause a problem if your internal domain is different from your public domain name. So, your Windows domain could be something like mydomain.local, but all of your public-facing servers are mydomain.com. In that case, when you terminal server asks your DNS server for the IP address of www.mydomain.com, your DNS server says "I don't know, but I only know the addresses for mydomain.local. Let me send that off to try to find the IP address for you." And then it eventually gets a response back from your DNS hosting provider and gives you the correct IP address. But, if your internal domain name is mydomain.com and your public-facing domain name is also mydomain.com, then when your terminal server asks your DNS server for the IP address of www.mydomain.com, your DNS server says "I don't have a record of a host named 'www'. I'm in charge of this domain so if I don't have this record then no one does. Therefore there is no such server." This problem can be overcome by manually entering host records on the internal DNS server for all of your public-facing servers -- basically duplicating all of the entries you have your DNS hosting company make. Anyway, that is all assuming that your internal network is a Windows domain with a DNS server. If you only have this one server, and it is pointing out to a DNS server on the internet somewhere, then there is another problem, but probably still related to DNS.

If the policy has already been enabled and defined at a higher level then they will show up that way (disabled buttons).

Is your server a domain controller? On domain controllers, the Remote Desktop Users group has been removed from the logon via terminal services right, but it can be added back in.

I'm assuming that your terminal server is pointing to your inside DNS server. Is your internal active directory domain also mydomain.com? Do you have a host record on your internal DNS that has the hostname and IP address for www.mydomain.com?

You can also take a look at the remote desktop connection from the client machines. If you go to the Local Resources tab in Remote Desktop Connection, then click the More... button down near the bottom, another window will pop up. In that window you can expand Drives and click the checkbox for any of the client drives that you want to show up in the remote desktop session. That way, when they are remoted into the server and open Windows Explorer, in addition to server drives, they will see something like "C on client" or "D on client" and will be able to interact with it like a local drive.

When you say that you have to put in the IP address of your site, is that a public IP address or are you talking about having to put in private IP addresses for internal computers? If the address you are putting in is a public IP address, you should be able to create a DNS record with a hostname for that IP address. If your DNS is hosted by someone else, you will have to ask them to make the change.

Hi, Joe, That's a lot of questions, but let's see what can be answered. First, licensing. - You don't need to worry about licensing for local accounts on the server. You can have as many profiles on the server as you want. That's pretty much covered by the server license itself. - The CALS each cover one PC or user that connects to the server through the network. - In Windows Server 2008, you no longer need CALs for each person who accesses a web site hosted on the machine. Second, RDP. Only two RDP sessions to the server can be active at one time in administrative terminal services mode. If you will need more than two RDP sessions active, then you will need to install what used to be called Terminal Services but in Win2008 is called Remote Desktop Services. While these services can be installed for free, Microsoft expects you to purchase terminal service CALs for the clients. VPNs are set up through Routing and Remote Access Services. That counts as a connection for server CALs. IIS is the built-in web server service for Windows. It isn't installed/active by default. In Windows 2008 you would enable the Web Server Role to install the services. I think that covered most of your questions.

x64 Server 2008? If so, the drivers may not match what is on the client. You should have some entries in your event log about the remote client not being able to map the printer because it can't find a driver. If that's the case, you may need to update the drivers on the clients. You can also check the group policy settings in this article.

Briganca, it sounds like you want to install Windows Software Update Services (WSUS). That link is for a word document with step by step instructions.