About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Server 2008 R2 SP1 AD errors

At a customer site doing some due diligence on AD health.  DCDiag from the first Exchange 2010 CAS server against the FSMO holder failed on the DFRSEvent and KCCEvent checks with an event ID of 0x6BA.  Running the same test on the FSMO holder (we need to extend the schema folks!) failed with 0x6BA also. 

Once we got the first issue reduced, then another popped up on both the FSMO holder and the DCDiag from the Exchange CAS server:  0x8000043B

Doing a little googling revealed this blog entry that got me started on fixing the issue. However, this blog entry clearly stated that the “Remote Service Management (RPC)” was the culprit. 


Enabling this rule in the DC’s firewall did not help me; so I started with all the rest that looked like they might be what I was looking for.  Not the most scientific method, but my reasoning was that it was better than turning the FW off entirely.  Also, all other data I could find for this issue all pointed back to the one blog – that guy should be charging for plagiarism!  For my situation, we had to enable this other rule also:  “Remote Administration (RPC)” as shown. 


At this point, DCDiag /s:fsmohost completed so quickly you would have thought the entire thing errored out.  Instead, what it did was pitch the KCCEvent event ID:  0x8000043B.  Not good, I still need the FSMO holder to behave so I can extend the schema (amongst other tasks…).  After wading through more googles, the fix to this second layer of error was:

dcdiag /fix

wala!  Nice clean dcdiag runs from both the FSMO holder and the exchange servers. 

No comments:

Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...