Same thing here, JCimarex. Funny you mentioned SCCM because that didn't cross my mind until you mentioned it. That's how, via WSUS, our updates are pushed. The only fix (scratch that, preventive measure) is to wait until this is acknowledged
by Microsoft and, until then, not to apply any updates that may cause this issue. We have determined the most likely culprit to be KB2975719. That was through using WSUS reporting to create reports on the updates applied to servers which were and
were not experiencing the problem. In separate, mutually trusted forests, we have another 43 DC's - all of which run the DNS Server role (obviously). Out of those, and the 9 other ones (52 total that we have investigated), the one commonality is
KB2975719. That isn't to say that is the actual culprit, but we have declined these updates until a fix is released for this issue.
I am going to be getting in touch with enterprise support this week regarding this and a few other issues we have seen with recent updates (including hangs at starup with "Please wait for the XXX service" - typically XXX is Desktop Service or Local
Session Manager). Again only recently updated servers have this problem (and the boot problem is not limited to domain controllers).
So, the main advice I can give to hopefully help someone out is to fully vet the KB articles on all updates that you approve for installation on several factors.
1) Is it critical for security and does it even apply to our environment? If so, we typically approve it (again, critical meaning truly critical - not a "this might happen in rare circumstances" type of thing).
2) Is it isn't critical, does it fix some other issue we are having? If so then we look at possible side-effects of the update and, if ( benefit > risk ) install the update.
3) If it is a generic "This update fixes issues with Windows" type of thing, barring no additional information available, we decline it until further notice.
4) All other, low importance updates are declined.
Again, this is just our current work around, and I'm only referring to installing updates on servers that are critical in our environment. The biggest saving grace for us is, on virtual machines, to take a full (e.g. including RAM) snapshot while it is running
IMMEDIATELY prior to installing the updates. Then, thoroughly check it out after the updates have completed. If there is a major problem, try to identify the problem quickly (we just export all the logs to a network share for offline viewing) and
revert as soon as possible to the running state snapshot. Then, unselect the updates which may have caused the problems and take another snapshot and repeat. Don't get into an infinite-loop, though! :)
I mention doing the process quickly particularly for Domain Controllers. While new versions of Server 2012 and R2 handle snapshot pretty well, there still exists potential for causing replication failures when reverting a domain controller from a snapshot
(because the KCC doesn't know what to do with the old data that is trying to be replicated). That is also why it's important to take the snapshot in a running state and to include a quiesced filesystem and the contents of the RAM.
I hope this helps someone and I certainly hope MS comes out with a fix for this soon.
Zac
Other recent topics
