DLAS

Yep that's definitely a viable alternative, we've done this with a few applications in the past and it works fine. Cheers for the suggestion. I do prefer (Because it's neater I suppose) to supply the link through the start menu if possible - plus I'm actually curious as to what is causing this now!

I didn't think of that, have just done a quick test and that doesn't seem to be the issue... Thanks

That's pretty much what we've done. Cheers! Everything is ticking along nicely now on the domain.

Hi, I've just installed a new application on our Windows 2008 RDS server, the installation is all fine and the application works as intended etc... I'm just having a problem getting the icon to appear in the start menu for all users. I've added a folder and shortcut for the app to C:\ProgramData\Microsoft\Windows\Start Menu\Programs but the Icon hasn't appeared. If a user types the name of the app into the Start Menu search function then they can find the app and launch it with no issues - it's just getting the icon to appear. There's no redirection in place on the start menu. It's a strange issue because normally when the App is installed and a shortcut is added during installation, then there are no problems. Any ideas? Thanks!

It was WSUS!

Now we're well after hours I've been in a position where rather than removing the server from the network, I've been able to remove all the clients from Site B. Without any clients at Site B the VPN is also very low on badnwidth usage, and the connection at Site A works perfectly. So it's definitely some communication from Server A to Site B client PC's because the problem goes away when either - *Server A is removed from the network* or *all clients are removed from the network* I suppose this test at least rules out any communication issues between Server A and other networking equipment - routers, switches etc... Now just to figure out exactly what it's sending to the client machines via VPN... I'm going to do a pretty lengthy mid-day packet capture from the server tomorrow to get a better idea of what is being communicated. Hopefully that will help.

There's no particularly noticeable increase in resource consumption at all on Server A - the CPU is sitting constantly around 5-10% as the server isn't used for too much these days. When the VPN was established there was no constant increase. By the way - thanks for your continued help with this!

Each site has it's own Internet connection, so I wouldn't expect it to be internet traffic. I'm absolutely convinced it's related to the DC at Site A in some way due to the fact that when I 'block' it from the network (Using a feature on the router) then the traffic over the VPN is basically non existent. The minute I 'allow' it back on to the network the traffic down the VPN tunnel increases dramatically and the connection at Site A becomes more or less unusable. It's all 1 way as well, so looking at the VPN from Site A's router shows all the data is being transmitted from Site A, whereas it's barely receiving anything from Site B. I just can't see what would be causing it... absolutely stumped. As I said, Wireshark shows the majority of the traffic to be SMB protocol, but there are other protocols that the DC is sending, like SPOOLSS and DCERPC.

There shouldn't be any print jobs going through the VPN - each site has it's own print server. Site B has an OU in group policy that prevents the use of roaming profiles for now. Ideally the only sort of communication we want down the link (as you've said earlier) is between the Domain Controllers. As for the machine that was the destination for alot of traffic, there isn't anything odd about it or how it's being used at all. The majority of the traffic going down the link was from the Site A DC and was SMB protocol.

So, you're probably sick of me at this point but... What would cause the DC at Site A to put a huge amount of traffic down the VPN to site B? We've noticed that the performance at Site A is diminished due to the VPN stealing the bandwidth of the connection at that site. I'm certain it's the domain controller at Site A that's the problem because as soon as I block it from the network, then the VPN traffic is reduced to nearly nothing and the connection is back to performing perfectly. Then as soon as I re-allow the DC at Site A back to the network, it over taxes the VPN and cripples performance at that site. I've grabbed a Wireshark capture that I ran on the DC at site A but interpreting it is a different story. It seems there's alot of traffic being pushed out to a specific machine at Site B. This machine is just a normal client PC with nothing unusual about it... This one has me puzzled. Have you ever seen anything like that before? Thanks

I missed the global catalog setting, that's fixed it. Cheers again Michael.

Hi Michael - that's exactly as we have it setup. Dcdiag has just thrown up some errors we can look into though with the netlogon share.

Looks like I spoke too soon. If I take the VPN link between the buildings down then the new DC at Site B won't authenticate users. It seems to work fine for DNS though - if I used NSlookup with Site B set as the DNS server on a client then I can resolve both internal and external hostnames to an IP. If I try and RDP into the new DC at Site B when the VPN link is down then I get a "The system cannot log you on due to the following error: the specified domain does either not exist or could not be contacted" So at the minute users can only authenticate when the VPN link is up - should that be expected? When the link is up there's huge traffic going down the VPN from Site A that's slowing the connection at Site A. How much would you expect to be pushed down the VPN link with a physical DC at each site? It's almost like the DC at site A is still doing all the work. Any ideas? Thanks

Completed!

Only just seen your further posts - thanks Michael. That's exactly how we've set it up and it works perfectly!