Sites without a local DC/GC

install a local Gc/DC local to each site.

That is the easy answer... But I cannot for several reasons...

So, any alternative?

install redundant WAN links...

We have that but the results are proving that with or without backup WAN connection, the behaviour is the same...

are you sure the backup wan connection is working?  When using only the backup WAN connection, can you ping, or use NSLOOKUP to resolve to servers in the main site (from the remote site)?

yes, the backup lines are working.

But the problem is that it becomes so slow when it switch to the backup lines that it is impossible to work.

So, it there en alternative for the users without a local DC/GC to be able to work without the network link to the closest DC/GC being available?

Best solution:  Install DC's in all sites

Second Best solution: Install working redundant WAN links in each office (make sure speed of WAN link is suitable to constitute a healthy working environment)

Third Solution:  Have users login using cached credentials... in other words, if the links go down, have users login to the domain anyway...the domain controller will not be found, but if the user has logged on once before, they will be able to login using cached credentials.  This is very much like what happens to a laptop user when he/she is off the network logging in....  However, the users will be very limited on what they can do when using network resources.  This is because the domain is offline from resources in this remote office.

Yes I know the cache credentials behaviour...

This works well in theory but give nothing in practice... What we have seen it that an already logged on user cannot even access a normal share or printer on the file and print server if the link to the DC/GC is down...

So, we have to find a workaround for this... Suggestions?

You have been given some sound advice above but for some reason you are looking for an answer that does not exist.  If you authenticate across the WAN and your links go down, short of using "The FORCE" there is nothing you can do about it.

Your cheapest alternative is a local DC/GC with DNS and DHCP.
Your most expensive would be another link.

You say "local" resources - if these are network attached printers, then create local IP ports and make them machine dependent rather than mapping to a print server which is profile dependent.  If you have a file server local then what's stopping you from making it a DC?  

i am in agreement with Netman here, NJ has provided you with the only solutions available for your situation, there isnt any other options available! you can promote even a small machine to a DC and have your issue solved, thats where i would be heading

Yes, we have at least 1 server in each location and that server is part of the AD domain. So we could make it DC/GC/DNS and our problems would be solved.

But the problem here is that that local server is locally managed and we have around 600 locations for a total of around 50.000 users. The AD is centrally managed. So, if we make that local server a DC, we would have to give domain admins rights to the local IT guys managing these local servers which will be a DC. And of course, we do not want that for security reasons.

So, there are no other alternatives????

why give them rights, just manage it remotely if thats an option

Scainfra:  The environment that I work in is similar.  We have 150,000 users...and about 1500 sites.  We did not want our local office admins to have any rights on the DC's.  So we could not make the local file servers (in small offices) a DC (although, this would have solved the redundancy problem).  Therefore, the solution was to purchase additional hardware just so we could have an additional DC in each office.  Redundancy costs money.  sorry, there is no other solution that I can think of...  maybe someone else can...

good luck

You could do one of two things.

1)  Make these servers DCs with a GC and DNS, then delegate the required administrative rights - but NOT Domain Admin.

2)  Load Virtual Server on each file server and load a DC up in the VM.  As long as the local Admin presence knew what to do/not do with respect to VS then they would have no rights whatsoever on the DC running inside the VM.

Hi Guys,

Thanks for all your comments, I really appreciate.

In the meantime, I think I found an interim solution for our sites running without DC and with no connection to a remote DC when the WAN link is down... I will share it with you, maybe we could discuss and improve that idea...

In these small sites without DC we have local resources like file and print servers. For our users, the most important is to be able to continue to work with these local resources even during the time the remote DC is unavailable because of a WAN link failure and the site is then isolated from the rest of the work. In all our sites, all users are connected to their resources via login script.

So, here is what I did...
On the local servers I created the same account locally in the local standalone user DB. That local account has access to all resources running on the servers. It is in some way a local admin account on all servers. On the client computers I have an emergency script which runs their normal login script under that account. In the case the DC is unaccessible because of a WAN link break, I ask the users to double click on that script file. The script disconnects all resources from the computers and reconnects the same resource but under that local account. Some kind of pass through authentication if you want.

I am currently piloting this solution and apparently it works fine. I know this is not the best solution when we are talking about security but at least it works and the users can continue their tasks during the windows the DC and WAN link is unavailable.

I hope you understand my explanation and all comments are welcome...

Regards
Greg

mate if it works it works no one can argue that :)