Force DFS-R into a dirty state

Question

We use Windows Server 2012 as our file system running DFS-R between our two sites as part of our business continuity systems. Last week, DFS-R failed at one site requiring the file server to be rebooted. The same thing has just happened at the other site causing several hours of downtime whilst we tried to resolve - although now we know to simply reboot which isn't nice.

The DFS-R service is currently disabled whilst we diagnose the root cause (timeout errors in ESENT) but I'd like to bring it back online overnight.

I'd like to be able to force the same code that runs when a dirty shutdown occurs, i.e. check the database when the service is restarted. I know this takes many hours but I'd prefer that than bringing up a service that might instantly fail again.

Is this possible?

Simply stopping the service isn't doing that? Every time I do, I get DFSR whining at me about a dirty shutdown state. — HopelessN00b, Mar 04 '14 at 14:11
Not for us - it usually comes back up cleanly unless it was a dirty shutdown; we have had one when the Hyper-V host crashed — Rob Nicholson, Mar 04 '14 at 17:12
I will be restarting the service this evening and will be watching the event logs *very* carefully — Rob Nicholson, Mar 04 '14 at 17:13

score 2 · Answer 1 · answered Mar 07 '14 at 01:46

2

Well you could delete the database and cause dirty shutdown recovery if you really want to.

But I think what you should really do here is take a backup, gather the debug logs (for analysis) as is and then decide whether you want to start the service or perhaps re-initialize the RF/database.

You need to pick a server to be the starting primary if you are going down this route.

Debug log analysis docs if you want a stab at log analysis are here: http://blogs.technet.com/b/askds/archive/2009/04/09/dfsr-debug-log-series-wrapup-and-downloadable-copies.aspx

answered Mar 07 '14 at 01:46

maweeras

2,734
2
17
23

In the end I restarted it and it came up cleanly. But the same fault that prompted this post occurred again on Wednesday night requiring an all night session to take the down-time opportunity to update the servers. Not nice. DFS-R is a critical part of our business continuity plan (replicate to sister site) and we need it to work reliably. It had worked reliably for six months and then start wobbling at all three sites. Whilst watching updates install through the night, I was reading about the improvements in DFR-2 in R2 with interest... – Rob Nicholson Mar 07 '14 at 11:43
You may have an issue that merely needs to be troubleshooted. I suggest raising a case with Microsoft if you need help with log analysis. You do obviously want to find a fix and/or perhaps root cause (assuming you have data to determine this or repro steps) so you can get that reliability back. – maweeras Mar 07 '14 at 13:43

Force DFS-R into a dirty state

1 Answers1