We help IT Professionals succeed at work.

WFE in the DMZ

QPR asked
We have an internal (medium) farm and have the need to publish a large document library out to the web.
This web server is not on the internal network but accessible via http/ftp
The doc library (on the web server) would only be accessible by around 10 people (no anon access)
The content would be > 2GB so SQL Express is no good.

Can somebody advise
Is this possible
Potential problems
Costs involved with an outward facing WFE
Watch Question

1.- Decide how they're going to authenticate... eg: do they have an AD/local account... I would say yes for 10 people, if not create them.
2.- Assuming you've decided AD/local accounts above it's pretty easy just open a port to the server... reverse proxy/NAT... or u may not even need to since u said it's accessible over TCP.
3.- Set permissions up so they just have access to the doc library.

They'd just need to enter their AD user/pwd in the browser and hey presto.


these are non-domain users who have had password created locally on the stand alone web server.

So I can add this WFE to our existing farm even though the server is not on the (domain) network?
Any idea of the costs involved with this? (excluding SQL)? Can you add a WSS server to a MOSS farm or do all the WFEs need to be running the same version?

Is this a completely separate environment or do you want them to access your existing farm?

So I can add this WFE to our existing farm even though the server is not on the (domain) network? No the server need to communicate with each other.

All WFE must have the same version.

M$ "want" you to get an "Internet Connector License" for every machine visible on the internet.


Let me get this straight.

1.- u have an existing environment with say WFE + DB on local domain?
2.- u want to add another WFE off the domain and connected to the domain DB?



We have an internal MOSS environment. 1x SQL Server 1x App server.
On the app server we have a doc library (word docs, pdfs, images, meta data) that we'd like to somehow replicate online for a few users.
I have done some ugly work arounds using asp.net to extract the data (from sql) including the BLOBs which I then FTP to the external site.

Without being in a WSS environment the collection of docs is ugly, hard to navigate/manage and has zero meta data.

To address this, one of the thoughts I had would be to have another WSS environment on "the outside" which would then have a doc library set up to mirror the internal one.

If this can be done using a separate WSS instance or needs to be done by extending the existing farm to somehow communicate with the internal servers then I'm all ears.
By far the easiest and my recommended way would be to reverse proxy to you existing environment.
You only need to extend the web application if you're changing the authentication method.

Here have a read of these to get an idea what's involved:

I know you only want to share 1 doc library, but it's the same as sharing everything.


thanks that looks great, I'll have a read up

Would this mean that the external users would need to given a domain login in order to get to the internal library? We add/remove users to sharepoint from AD for WSS access.
We wouldn't want to give these external users domain rights as we have libraries that "domain users" have view access to that we wouldn't want these 3rd parties being able to navigate to/view

Yes, u'd need to create an AD account for them, BUT you can always create them in a separate organizational unit with limited rights and since they're only able to access over TCP 80, they'll be very limit they can do outside of sharepoint.


it's inside of sharepoint that we are worried about
"domain users" (the built in account) has view permissions on all doc libraries in this site. We want the 3rd parties to only have view for this doc library. If they log on to the domain they will automatically inherit  domain_name/domain users membership won't they?

Yes... just replace the  domain_name/domain users (catch all) permissions from the sites they shouldn't have access.
Create groups or use AD groups.


Nearly all of our sites are viewable for domain users (think Intranet). By dialing in (so to speak) they will authenticate against AD and then become a "domain user"
We use non-inherited permissions on specific sites where data is sensitive
Even if we use unique permissions on this site, would they not see ways to navigate elsewhere by virtue of being a "domain user" e.g. quick launch, IE address bar etc.
These were the reasons we were leaning away from them "coming in" and instead trying to do some form of replication to a WFE in the DMZ

Well the choice is yours.

A: Replicate an environment, deal with synchronization issues.
B: Implement security.

Think of it as a building... say you have an office with 10 floors, the building has 1 key and if you have that 1 key you can go anywhere in the building. Now a new manager comes in and wants some contractors to work on level 5 but not be able to go to any other floors.

Do you
A: Build a new floor
B: Lock the other floors

You can extend the web application then using the web.config file restrict access to various pages, like "People and Groups".


We are talking 300+ managers/locks/keys with many sites, nearly all of them open to domain users and only 1 of them to be accesible to outside parties. It's a shame we dont have revoke like SQL server.