I'm working for a company that has a head office and some remote sites. We have an Active Directory server in the head office and we now want all of the users in the remote sites to join and work on the domain at the head office.
I want to assess our bandwidth to see if we have enough to carry all the traffic between offices smoothly. What can I do or which tool can I use for the assessment and statistics?
Without knowing what services your providing beyond authentication (such as group policy, file/print sharing, etc), This is what I would do.
Start with your remote sites, one by one, establish a link back to hq, most likely via vpn.
Join your workstations to the domain. Make sure the users can access the necessary resources in the process (file/print sharing, group policy is working, etc.)
Keep an eye on the bandwidth at the remote office as well as at hq. Everyone has their own opinion about this, but If I see bandwidth utilization consistently above %75 throughout business hours then I would be looking to upgrade the link at that location if it's in the budget. Peaks above this are fine, and to be expected. As for the tools to use for this, it depends on what you're using along to route your traffic. PFSense for example has a built in traffic graphs that will show you how saturated the link is.
I'm sure other business grade routers have similar tools. If you're looking for latency, tools such as SmokePing can help you monitor latency from the remote office to hq.
Lastly, as mentioned above, it's a constant process of monitoring the network, both at the remote site and at hq, because as the needs of remote offices grow, so will there bandwidth requirements. To curve this, if some offices are big enough, it may be worth it to setup domain controllers and/or other servers on site. This has the advantage of having only that server talk back to hq, preserving a lot of bandwidth in the process, when using technology such as BITS, which MS pushes these days.
If they are only using it for word documents and AD authentication, the workload will probably be quite low - but there are a lot of other things to consider such as:
Will their web traffic be sharing the same line? How about email? How many computers/users?
There isn't really a way to reliably estimate the traffic you intend to create.
Also, have you considered the possibility of installing an RODC and DFS box at the remote site to lower the load on your network WAN links?
Hope this helps
I run a network with several remote offices connected by site-to-site VPNs over cable/DSL lines.
If you are just worried about active directory traffic - it's very minimal. Pretty much negligible. File shares are a completely different story, and that's going to depend entirely on what people are doing with their files.
We have a few small offices (3-10 people) where there are no servers, everything is saved on the file servers at our head office, where we have fibre and plenty of speed. This works quite well as long as their internet is reliable. Do keep in mind that you are limited to the slowest speed in both directions - if you have 5mbit down/1mbit up cable at both locations, you're pretty much limited to 1mbit speeds - since one side will always be sending, and the other side receiving.
For larger offices we install a server on site which functions as domain controller and file server. This allows them to do some work even if their internet goes down. Backups are done overnight to our head office when nobody needs the internet.
This works fairly well. We have run into a few issues - people trying to save music and videos to their network drives for example (which was in some cases actually work related).
The only thing you can really do is try it. Start with the smallest (in terms of staff) office, and monitor their bandwidth usage. If things work fine, and staff aren't complaining too much, move on to the next biggest one. When you do start getting complaints, increase bandwidth or try adding a domain controller/file server at that site and things should improve. They don't need to be brand new servers - we upgraded ones that really needed it, and took the old ones to the remote offices.
