faulteh
asked on
SBS 2008 with a remote site
I have an SBS 2008 server, and a remote office with 6 or so people in it. There is increased interest in using sharepoint for document collaboration. The issue I have with the remote site is that I know you get a lot of password prompts unless you're on the domain. The offices are about 5 hours away from each other physically. I don't want users logging in over the WAN (for obvious reasons) even though they have a site to site vpn.
I'm considering putting in a low-end server (w2k8 standard) and using it as a secondary DC and GC and setting up synchronization for after hours.
Does anyone see any issues with this?
Will it succeed in eliminating the majority of password prompts (even if signing in through RWW to sharepoint?)
My initial plan is to build the server in the main office, dc promo, let it sync. ship it to the remote office to allow them to log on locally. Also, will the "connect" computer wizard function from remote or would it be incredibly slow? the majority of the work happens on the local pc I would presume.
I'm considering putting in a low-end server (w2k8 standard) and using it as a secondary DC and GC and setting up synchronization for after hours.
Does anyone see any issues with this?
Will it succeed in eliminating the majority of password prompts (even if signing in through RWW to sharepoint?)
My initial plan is to build the server in the main office, dc promo, let it sync. ship it to the remote office to allow them to log on locally. Also, will the "connect" computer wizard function from remote or would it be incredibly slow? the majority of the work happens on the local pc I would presume.
Brian Pierce
No reason why you can't to this - you could use DFS to replicate the data if you really want. Personally I don't see the reluctance to use a VPN, thats what is designed for
what's the difference in security between having your users lgo into RWW via VPN, or having your servers sync via VPN? both are encrypted just fine.
the many login prompts can be adjusted in IIS, the default timeout is 10 minutes or something stupid, we set ours to 9000 minutes and have been ok for months.
the many login prompts can be adjusted in IIS, the default timeout is 10 minutes or something stupid, we set ours to 9000 minutes and have been ok for months.
Why not just use your internet connection and all you would need is a third party SSL SAN cert and away go the additional prompts for logins to companyweb, rww, owa. Then you wouldn't need a vpn and all connections would be secure. Your users from the remote office would simply connect via "remote.externaldomain.com
Even though in SBS 2008 a Self-Signed Certificate is supported for use with domain-joined Microsoft Office Outlook 2007 clients and Outlook Web Access, I do not recommend long term use of the self-signed certificate for any purpose other than encrypting communications between Exchange 2007 servers within your organization. I recommend that to support many, if not all, of the Client Access server features such as Exchange ActiveSync, Outlook Web Access, and Outlook Anywhere, you obtain a certificate from either a Windows PKI or a trusted third-party CA and make sure that this certificate is imported using the SBS Console SSL Certificate wizard.
When you run the Internet Address Wizard you need to just tell it you already have a domain and you will manage it yourself. This should let the wizard complete and configure exchange with the proper smtp addresses. I also never let the wizard configure my router. I'm usually a wizard guy but this is one area I feel more comfortable in setting up the router myself and it usually fails if the router isn't upnp.
When it asks for your external address i would use the default "externaldomain.com" or "remote.externaldomain.com
Then create a multi-domain certificate from godaddy or someone like that. The configuration of the Subjective Alternative Names (SAN) would be something like this:
remote.externaldomain.com
sbsservername.internaldoma
sites.internaldomain.local
autodiscover.externaldomai
There are others you could use but these are the basics.
You will need to modify your existing external DNS with these records that are externaldomain.com I prefer to use a wildcard * to redirect everything that is not specified. The wizards will configure the rest for internaldomain.local.
This normally takes care of internal issues and external issues.
I hope this is helpful and if you need further clarification or I have misunderstood something please don't hesitate to elaborate.
You need to abstract the physical design from the logical design here.
Logically, you need a single domain/single forest. The physical placement is the question here.
1. Logon over the WAN - no real issue here... How many users do you have at the remote office. Does your WAN Connection have more than 0.192kbps of spare bandwidth? If so, 0.192kbps will accommodate 100'000 users in a single domain. Bandwidth is hardly ever the issue with server placement anymore...
2. Place a full DC at thre remote office - potentially a security issue
3. Place a Windows Serverr 2008 Read Only DC (RODC) at the remote location
The artical below may also be of interest to you:
http://robsilver.org/ad/active-directory-domain-consolidation-part-i-%e2%80%93-why-you-need-it/
Hope this helps,
Rob
http://robsilver.org
Logically, you need a single domain/single forest. The physical placement is the question here.
1. Logon over the WAN - no real issue here... How many users do you have at the remote office. Does your WAN Connection have more than 0.192kbps of spare bandwidth? If so, 0.192kbps will accommodate 100'000 users in a single domain. Bandwidth is hardly ever the issue with server placement anymore...
2. Place a full DC at thre remote office - potentially a security issue
3. Place a Windows Serverr 2008 Read Only DC (RODC) at the remote location
The artical below may also be of interest to you:
http://robsilver.org/ad/active-directory-domain-consolidation-part-i-%e2%80%93-why-you-need-it/
Hope this helps,
Rob
http://robsilver.org
RobSilver:
Your bandwith estimation is crazy. 0.1Kb will NEVER support 100k users. What are you talking about? Are you utterly insane? Bandwith (and response time)is always the issue with server placement.
Conchcrawl suggests a good solution, and something you should do as a standard implementation of SBS 2008. Always buy a proper certificate for your server. But I'm suspectiong you have done some other terrible misconfiguration here....
Am I correct to asume that you don't have your clients at the remote office included in the domain? That is pointless. What's your bandwidth? You should include them in the domain at once. Logon over a WAN link is harmless as long as it is encrypted with site-to-site VPN. ANYHOW, the logon process is encrypted in itself. What is of more concern is the other network traffic going between the server and the computers. Well, VPN is safe, so don't bother with that thought anymore.
RWW and sharepoint will be delivered from the SBS, hence the logon process happens there. A new DC will not help you on this matter.
But leaving the computers out of the domain is just crazy.
1. Install another DC on the remote office. Make it a GC, DC and DNS server. Make sure your DNS zone is AD integrated.
2. Join all computers to the domin through the http:\\connect page.
3. Understand your network shares and profiles. Do the remote office computers have roaming profiles or folder redirection? What other resources do they need access to?
Just get it done.
Your bandwith estimation is crazy. 0.1Kb will NEVER support 100k users. What are you talking about? Are you utterly insane? Bandwith (and response time)is always the issue with server placement.
Conchcrawl suggests a good solution, and something you should do as a standard implementation of SBS 2008. Always buy a proper certificate for your server. But I'm suspectiong you have done some other terrible misconfiguration here....
Am I correct to asume that you don't have your clients at the remote office included in the domain? That is pointless. What's your bandwidth? You should include them in the domain at once. Logon over a WAN link is harmless as long as it is encrypted with site-to-site VPN. ANYHOW, the logon process is encrypted in itself. What is of more concern is the other network traffic going between the server and the computers. Well, VPN is safe, so don't bother with that thought anymore.
RWW and sharepoint will be delivered from the SBS, hence the logon process happens there. A new DC will not help you on this matter.
But leaving the computers out of the domain is just crazy.
1. Install another DC on the remote office. Make it a GC, DC and DNS server. Make sure your DNS zone is AD integrated.
2. Join all computers to the domin through the http:\\connect page.
3. Understand your network shares and profiles. Do the remote office computers have roaming profiles or folder redirection? What other resources do they need access to?
Just get it done.
0.192kbps to be more accurate. Also, notice the term 'bandwidth to spare'.
Regards,
Rob Silver
Microsoft Certified Master
Regards,
Rob Silver
Microsoft Certified Master
ASKER
I have an SSL certificate. Unfortunately, it was only for the remote.domain and doesn't have alternate names. That is something we will have to look at.
The remote office is not on the domain currently and I understand the logical implementation of this. Good to know that logon speed wouldn't/shouldn't be an issue.
Bear in mind I inherited this mess as a consultant, so I'm working on unifying all their operations.
The remote office is not on the domain currently and I understand the logical implementation of this. Good to know that logon speed wouldn't/shouldn't be an issue.
Bear in mind I inherited this mess as a consultant, so I'm working on unifying all their operations.
And what traffic is it that you plan to run over that bw? Have you taken out just the logon traffic and ignored the rest of the infrastructure communication? If you are asking faulteh to join the remote computers to the domain, then I agree with you on that issue. Maybe I've misunderstood you. But I don't see the point in bragging detail knowledge of bw consumption for logon traffic since it's just a very small portion of the traffic that would run through the WAN link. GPO's, redirected folders, name resolution needs also to be considered. And those are the issues that make DC placement rely on WAN links still. Replication of AD, GPO and so on.
ANYHOW he was talking about adding a DC to the second site, which would rule out the logon traffic.
ANYHOW he was talking about adding a DC to the second site, which would rule out the logon traffic.
Faulteh:
Don't hesitate. Join the computers to the domain at once. But put them in their own container in AD and make sure they are not affected by any of the SBS policies. Especially the folder redirection policies since they would synchronize all the local computer content in the given folders to the server. You can to be sure block inheritance of SBS policies on the new OU or even filter out the GPO's by assigning the new computers DENY "read" and "apply policy" rights on the policy itself.
Joining the computers to the domain is the solution that will rid you of all the password prompts.
Do the remote office computers access RWW over the internett or via the WAN link? Are they configured to use the SBS 2008 for DNS? If the SBS is set up correctly, there should be a DNS zone there for your external name (i.e. remote.domain.com). this makes RWW and all IIS site accessible by the EXTERNAL domain name, even though the client is on the LAN.
How big is the WAN link?
Don't hesitate. Join the computers to the domain at once. But put them in their own container in AD and make sure they are not affected by any of the SBS policies. Especially the folder redirection policies since they would synchronize all the local computer content in the given folders to the server. You can to be sure block inheritance of SBS policies on the new OU or even filter out the GPO's by assigning the new computers DENY "read" and "apply policy" rights on the policy itself.
Joining the computers to the domain is the solution that will rid you of all the password prompts.
Do the remote office computers access RWW over the internett or via the WAN link? Are they configured to use the SBS 2008 for DNS? If the SBS is set up correctly, there should be a DNS zone there for your external name (i.e. remote.domain.com). this makes RWW and all IIS site accessible by the EXTERNAL domain name, even though the client is on the LAN.
How big is the WAN link?
ASKER
the WAN link is just a site to site VPN over the internet. Not sure what they have for bandwidth. One office has a dsl so like 768kb UP .
They are currently not using the SBS box for DNS, DHCP or anything else and they have a "file server" (a desktop which wide open shares) for shares.
We are not currently doing desktop or my documents redirection and none of the users have roaming profiles.
They are currently not using the SBS box for DNS, DHCP or anything else and they have a "file server" (a desktop which wide open shares) for shares.
We are not currently doing desktop or my documents redirection and none of the users have roaming profiles.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanks everyone.