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.
LVL 3
faultehAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Brian PiercePhotographerCommented:
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
0
B HCommented:
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.
0
ConchCrawlCommented:

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" and have acess to owa, rww, and  companyweb (i.e. sharepoint) with just the following configuration:
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.internaldomain.local
sites.internaldomain.local
autodiscover.externaldomain.com

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.


0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

RobSilverCommented:
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
0
rakoczyCommented:
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.
0
RobSilverCommented:
0.192kbps to be more accurate.  Also, notice the term 'bandwidth to spare'.

Regards,

Rob Silver
Microsoft Certified Master

0
faultehAuthor Commented:
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.
0
rakoczyCommented:
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.
0
rakoczyCommented:
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?
0
faultehAuthor Commented:
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.

0
rakoczyCommented:
:D I actually see that nobody has really answered your questions directly:

You wrote:
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.
**No problem in doing this. I don't think that synchronizing during work hours would be a problem either if its a small network (50-100 users). It will only be AD changes, SYSVOL changes and GPO changes that would synch.

Does anyone see any issues with this?
**When you join the remote computers to the domain you need to be aware of the folder redirection GPO's and if they are in effect in the domain. If they are, you need to be aware that the selected folders will be copied over the WAN link to the SBS server. Some users have large amounts of data in their local folders, and this may cause a slow link. A solution to this would be to check what folders are redirected, and then check the local content on each PC. Also consider preventing the GPO's from hitting the remote computers. Be aware that you'd want folder redirection because it copies local user data to the server for backup reasons. If you disable this, then a local harddisk crash would most likely cause the user to loose data.

Also consider any folder mappings in the company since they will need to access the folders through the WAN link. As another user suggested earlier, you can fix this by implementing DFS and accessing mapping folders through \\domain.name\fileportal instead of directly towards the server.

Will it succeed in eliminating the majority of password prompts (even if signing in through RWW to sharepoint?)
**No you will not. The passwordsprompts in RWW are coming from the SBS server. The authentication uses Windows Integrated authentication over RPC over HTTPS. This means that the users username and passwords are sent to the RWW automatically, and since the remote office are non-domain computers, the users are not recognized by the server. If you join the computers to the domain, all the password prompts will stop popping up.

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.
**The connect wizard should work, and it should now be slow at all. Unless you have terribly slow WAN link. It is correct that most of the work happens on the local computer.

There.. :D
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rakoczyCommented:
With you WAN link, I would set up a DC locally to replace the desktop for file sharing. It would also help out in the logon process. Make sure it controls DHCP locally and hands out itself as DNS for the local clients. Have the DNS server hold a copy of the AD integrated zone so that all DNS queries will go quickly. The DNS server should be identical to the SBS DNS server when you are done.

Then join all computers to the domain via the HTTP://connect wizard.

This will be a nice and working setup for you.
0
faultehAuthor Commented:
thanks everyone.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SBS

From novice to tech pro — start learning today.