Roberto

This is a tricky one. If this was _just_ a DC then I'd suggest seizing fsmo roles and a quick demote / promote cycle to give it a kick up the backside but that isn't an option here really. Speaking of FSMO options, are they all showing as available/sensible in ADUC and AD sites and services?

Is the sysvol share available? Can you connect to \\fully.qualified.domain.name\sysvol ? Can you connect to \\first server's name\sysvol and \\second server's name\sysvol?

Should be absolutely fine. Should also be fine to leave them connected and just choose which disk you're wiping carefully too, but there's no such thing as "too careful" for things like this, is there?

It should work with 2008r2 on the "second server", and Windows will certainly allow you to mix and match domain controllers so having a new 2012r2 server alongside the 'old' 2008r2 server wouldn't be an issue for either DC services, DNS or DHCP. You'd need to effectively set up an 80/20 split and manually failover between the two DHCP servers until you'd upgraded both to 2012 or newer for DHCP resillience however. You'd want to speak to RM (or wait to see if someone who knows CC4 better than I can advise) to ensure you can stand up a none-CC4 DC in a CC4 network. I seem to recall previous versions of CC used to get in the pouts a bit if you tried this.

It could go on a laptop in the corner, but in that case what would the laptop run? It would really need to run windows server (in which case, why not a desktop built up a bit to act as a second server for DNS and AD too, running all the time?) or Linux with DHCP configured, rather than windows desktop.

Why a laptop? You can set any other server up as a DHCP server, and have it up and running alongside the current "live" one. Some notes here on that.

ok, have you read the following articles? Event ID 5774 | Ace Fekay https://support.microsoft.com/en-us/kb/284963 When did these changes start? Is the problematic DC multi-homed? Looking at the DNS server config on the other DC, do the DNS entries for the faulty one look sane?

ok pointing it to other DCs for its DNS client stuff is a good start. Does the DNS server service start? Errors in the event log? I would not be quick to seize roles or anything like that just yet.

Is that an absolute literal quote of the error message, question marks and all? It's possible for entries to get mashed in DNS. Stuff happens. I'm assuming here that you've checked the basics, that DNS for the domain is basically functional, that DNS *client* settings on the server are correct, etc. Assuming the _msdcs container exists in the AD DNS, this suggests that a DC's entry is missing from this container (or, more simply, the A record for the DC in question is missing). A simple fix that might work if that *is* the case, is to log on to the 'missing' dc and carry out the following steps from a command line: 1. ipconfig /flushdns 2. ipconfig /registerdns 3. net stop netlogon 4. net start netlogon

It was minix but we've subsequently had concerns about the long term quality of the boxen :-( Watch this space, as they say.

What do you mean by "malware protection"? There are plenty of antivirus options out there that will install onto a server quite cheerfully... admittedly the free ones tend not to (but aren't most of those licenced for just home use?)

This is the trouble with "dream houses"... you get emotionally invested in imagining yourself living there then things like this come up. I'm not saying its easy but I'd try and be businesslike about it. You have a budget. If you can't fit house plus repairs into the budget, walk away before your dream house becomes a nightmare.

I have my doubts, not sure if I'll watch the new TG, but it's great that there will be more choice and a bit of a shakeup around what's available. Both TG (for all my doubts) and that new Amazon show have the potential to be good. We can wait and see and try both on for size.

If the log files are large then this suggests that backups are not working. In Exchange (and other transactional database technologies) the log files are part of the database operation, not what we'd think of as "logs" from a human point of view. A successful "Exchange Aware" full backup of an Exchange database will clear the logs related to that database (and is the only safe way of doing so). If this isn't happening then either: 1) Backups aren't working (they could be failing due to DB corruption of course). 2) Backups aren't configured (self explanatory). 3) The restore you mention has somehow managed to incorporate a lot of extra spurious data that isn't causing a problem as such, other than it's "in the way" on the disk. Personally, I'd seriously think about spooling up another Exchange server and moving mailboxes to a database on that, at this point. If the log files are growing like that without any explanation then something seems very wrong with that Exchange server.

I don't think the powershell issue will be down to DB corruption per se. Having given this some more thought, I suspect that both symptoms are pointing to an underlying issue with storage. Normally at this stage, I'd be suggesting contacting Microsoft support. While it's not cheap to do that, it might cost less than *not* calling them in the long run. Are you getting storage errors in the event logs on exchange? Incidentally, you mention restoring Exchange to a new cluster - do you mean you have an Exchange cluster, or do you mean you have an Exchange server on a virtual server cluster? As for length of time for mailbox moves, it depends on all kinds of things - mailbox size (number and size of messages) is more important than number of mailboxes, along with disk and (if relevant) network I/O.

Because Microsoft don't support ongoing use of a suspected database (see New Support Policy for Repaired Exchange Databases - Exchange Team Blog - Site Home - TechNet Blogs). I think it makes sense, in light of what they say there, to recover whatever mailboxes you can to a new database *first* (use move-mailbox) then run eseutil on whatever's left then move the recovered mailboxes then shoot the old, suspect DB. If you interpret that policy literally, you could say "I haven't run ESEUtil *yet* and I don't need to evacuate mailboxes prior to doing so" but I think in terms of ensuring you protect and recover mail data as best you can, it makes absolutely no sense at all to use a suspect mail DB for a moment longer than necessary.

I would start by migrating mailboxes from the suspect database to a new one before doing anything with eseutil. What version of Exchange are you running?

Agreed. Used it many a time in the past with very good results, but I'd seriously think twice about using it for any new systems.

I used to swear by DITTO when diagnosing file or device issues on the IBM 3090.

Yikes! If there are concerns about data integrity then "trickin"g the backup software into using a method it doesn't support at all doesn't sound like the best way of improving that.

Yes. We block china and a few others. We've seen instances of attacks (from botnets, as has been pointed out) and things such as aggressive robot crawling of websites, and while I'm not *terribly* worried about this from a security perspective as we have IDS in place, it still represents a risk and also in the case of the crawlers, a load that some systems (Cirqa for example) struggle to cope with. Country blocking isn't something I do lightly as I broadly agree with the concerns that @Blue_Cookeh raises, but I do feel that in some cases the risks of allowing connections outweigh the benefits.

No. Not "fixt". *Whoosh*. We have over 40 high-end Procurve switches here and I like them a lot but that isn't the point I was trying to make. Precisely.

As has been pointed out, creating a superscope will do nothing for routing, which will need to be addressed too. Superscopes are rarely a good idea in my opinion. They are a complex way of solving a problem like this, it's nearly always preferable to just create a "proper" DHCP scope of the correct size.

On balance, I think I'd rather buy netgear.

As much as I loathe and detest them personally, I'd be looking at Netgear to replace hubs on a really tight budget. It's cheap and (I never thought I would say this about Netgear equipment, someone will need to get @Norphy to a fainting couch when he sees this) would represent a substantial upgrade on what is in place currently. http://www.businessdirect.bt.com/products/netgear-smart-switch-24-port-gigabit-10-100-1000-gs724t-400eus-98MG.html?q=netgear%20switch - can't argue with that when you're on a tight budget and hubs have been coping up to now... (Also, Hubs? Really? !!!!!)