This is pretty exciting.
Microsoft just shipped a totally new AD MP. This one has no dependencies on the previous ADMP, that has been mostly based on the same core design for the past 15 years!
https://www.microsoft.com/en-us/download/details.aspx?id=54525
The new ADMP supports monitoring Active Directory when yours DC’s are Windows Server 2012, 2012R2, or 2016.
There is a huge list of changes, but the biggest impactful ones in my opinion are:
- No more OOMADS!
- Removed Reliance on OOMADS.dll for Domain Controller monitoring removed oomads dependency from all MPs. This was always a pain when managing DC’s in the past, now it is no longer required for the ADMP scripts to work.
- Replication Monitoring rewrite.
- This was previously a nightmare solution of 14 rules and monitors which all shared the same script datasource, for EACH OS version you had DC’s on. Tuning replication monitoring in the past was very challenging for customers. Now – it has been streamlined via scenario, as Replication Monitoring was replaced with the following monitors:
- AD Replication Queue Monitor
- AD Show Replication Check
- Replication Partner Count Monitor
- Replication Consistency Monitor
- Removed dependency on down-level DC discovery MPs.
- You no longer have to import the old Windows 2000, 2003, and 2008 AD Discovery MP’s if you aren't using those versions, like the old MP’s required.
- A total re-write of the old “AD Client Monitoring” which is renamed to “Domain Member Monitoring”
- The Domain Member Monitoring Management Pack deploys a set of rules and monitors to a computer that represents an Active Directory member server or client. These rules and monitors provide monitoring data, such as connectivity, latency and availability, from the perspective of the member.
See the MP guide for the full list of fixes and updates.
At the time of this writing – the MP version is 10.0.1.0.
This MP does NOT UPGRADE the previous MP’s. This is designed as a replacement. However, you can run both MP’s side by side if you want to cut over monitoring slowly. You should delete all the previous older generation ADMP’s from your management group and use this MP, provided your DC’s are all WS2012 or later.
The MP’s import just fine:
The guide is pretty thorough on the monitoring scenarios – I recommend you review it before using the MP.
- Monitoring Scenarios
- Multi-Forest Monitoring
- Replication
- Essential Services
- SYSVOL Availability
- Trust Monitoring
- Directory Service Availability
- AD Database Monitoring
- Time Skew Monitoring
- AD Web Service Monitoring
- Domain Controller Performance
- Domain Member Perspective (the old AD Client Monitoring)
So, bottom line, do I still need to put all DCs in all trusted domains into maintenance mode to prevent an alert storm about replication, trusts, and/or FSMO role holders when I reboot a single DC? Or will putting that one DC into maintenance mode (finally) be enough?
There should no longer be an alert storm while doing maintenance on a DC. We worked hard to trim as many of the excessive alerts and noise generated via the MP. Depending upon the failure or status of your DC you may still get some alerts from other DC’s regarding replication but they are far fewer than the past. One of the ways we did this is via another big change in these MP's over the old ones. We no longer monitor via event logs. All alerts are generated from a synthetic test or performance counter on the DC.
Thanks for the information about the release/update.
Interesting that the MP Guide still mention the DFS Replication and Group Policy Management Packs as recommended as they are kind of outdated.
Regards,
Konstantin
Totally. I imagine those are just copied from the previous MP guide. The guide has several issues - like referencing the wrong version of the MP, and references to Windows 2003 which don't apply. So while the MP is new, the guide seems to borrow much from the old one and brought over some of its junk. I have provided feedback to the PG on this issue.
Also - the Group Policy MP is really poor quality, always has been, and should never be imported anywhere. It is a terrible MP.
OMG I have been dealing with the replication monitoring issue just recently....going through the pain of tuning all of those monitors/rules as you just described. Looking forward to testing out the new MP!
What an epic news. Maybe they will rewrite iis mp too..
Hi Kevin, just need a quick clarification on "ADMP supports monitoring Active Directory when yours DC’s are Windows Server 2012, 2012R2, or 2016" comment above. So as long as my domain controllers are running on Win 2012 and up even with "Domain Functional Level at Windows Server 2008 R2" I can use this MP and it will be supported? I went through the guide and didn't find any reference to the domain functional level requirements.
As always thanks for keeping us all educated on new SCOM stuff!
I am not aware of any domain functional level requirements for this.
The MP versions are related to the OS versions of the DC's. All forest functional and domain functional levels are supported.
Just a sanity check here, for the Domain Member Monitoring Rule, I should only put my DC's in this group as they're the ones I'm worried about replicating with. Correct?
You can put your DC's into the domain member monitoring group but that is not recommended. We recommend dedicating a member server to this group. The purpose of the Domain Member monitoring MP is to check the health of your domain from the perspective of a client. It is not always possible to know if a domain is responding properly to your clients via the DC. So, we implemented the Domain Member Perspective to give more insights into the health of your domain. Also, if you did not want run agents on your DC's for security purposes you could use the Domain Member monitor to verify the health of your domain without running any agents on a DC. One caution for monitoring your domain with the Domain Member monitor by itself...It will not monitor replication health or trust health. It primarily verifies that a client can bind to each DC in your domain and that it can find the FSMO owners.
Hi Kevin,
In the monitor "AD Show Replication Check" I think we found a mistake.
Dim sDomainDN
sDomainDN = oRootDSE.Get("rootDomainNamingContext") should be oRootDSE.Get("defaultNamingContext") to make sure it checks the domain with the short delay. (different delays)
If we don't change it, it only check the forest replication.
'Check for RootDSE and set shorter replication delay for that NC it doesn't check for both delays.
Thanks !
I can't seem to get these MPs to import properly for some reason. No errors on import, but when the monitoring MPs are imported, I am unable to access Overrides within the Authoring section of the console. I get the dreaded “An object of class ManagementPackClass with ID was not found”. As soon as I remove the monitoring MPs, this error goes away. Running SCOM 2012 R2 UR11.
Any suggestions?
Interesting - Mine works fine. But I had a predefined scope in place. When I deleted my scope - I got that same error. However, once I hit the scope button and created a new scope - no issues. Can you try that? It might be something left behind from an old MP in the console cache. So also clear your console cache.
Hello both.
In my environment (SCOM 2012 R2) with the last CU - I have the same problem regarding Mark issue.
After analyze the error code received when I select "Overrides" I find that the ID correspond to a rule present into the new AD MP.
I have uninstall the MP and after this, the problem don't appear anymore. MP as a bug !
I've try on another console on one on other MS and with the same issue thus I don't think is related to the cache.
Bellow the error :
Date: 09.01.2017 10:56:41
Application: Operations Manager
Application Version: 7.1.10226.1239
Severity: Error
Message:
Microsoft.EnterpriseManagement.Common.ObjectNotFoundException: An object of class ManagementPackClass with ID cade76f6-dc72-c29d-dc10-af14327ed5a3 was not found.
at Microsoft.EnterpriseManagement.Configuration.LegacyTypeSpaceCache.GetType[T](Guid managementPackObjectId, Dictionary`2 objectIdMap)
at Microsoft.EnterpriseManagement.Configuration.LegacyTypeSpaceCache.GetClass(Guid managedTypeId)
at Microsoft.EnterpriseManagement.Configuration.LegacyTypeSpaceCache.Get[T](Guid id)
at Microsoft.EnterpriseManagement.EntityTypeManagement.GetClass(Guid id)
at Microsoft.EnterpriseManagement.EnterpriseManagementGroup.Microsoft.EnterpriseManagement.Configuration.IO.IManagementPackSearch.GetClass(ManagementPackElementReference`1 reference)
at Microsoft.EnterpriseManagement.Configuration.ManagementPackElementReference`1.FetchElement(IManagementPackSearch searcher)
at Microsoft.EnterpriseManagement.Configuration.ManagementPackElementReference`1.GetElement()
at Microsoft.EnterpriseManagement.Internal.UI.Overrides.OverridesControl.GetOverrideScope(ManagementGroup managementGroup, ManagementPackElementReference`1 typeContextRef, Nullable`1 instanceContextId, PartialMonitoringObject& instanceContextObject, ManagementPackClass& typeContextObject)
at Microsoft.EnterpriseManagement.Internal.UI.Authoring.Views.OverridesQuery.CreateEffectiveList(ICollection`1 overrides, ICollection`1 interestedTypes)
at Microsoft.EnterpriseManagement.Internal.UI.Authoring.Views.OverridesQuery.DoQuery(String currentCriteria)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Cache.Query`1.DoQuery(String criteria, Nullable`1 lastModified)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Cache.Query`1.FullUpdateQuery(CacheSession session, IndexTable& indexTable, Boolean forceUpdate, DateTime queryTime)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Cache.Query`1.InternalSyncQuery(CacheSession session, IndexTable indexTable, UpdateReason reason, UpdateType updateType)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Cache.Query`1.InternalQuery(CacheSession session, UpdateReason reason)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Cache.Query`1.TryDoQuery(UpdateReason reason, CacheSession session)
at Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ConsoleJobExceptionHandler.ExecuteJob(IComponent component, EventHandler`1 job, Object sender, ConsoleJobEventArgs args)
The ID (cade) Nr correspond to a Rule into the new MP.
Best Regards
Thanks for the info. We have identified the issue and should have an update coming to resolve the override view.
The issue with the override view being broken is now fixed in 10.0.2.0 which is available.
Kevin, can you confirm that this is the only thing fixed in v10.0.2.0? I have an issue with how the Group Policy Update Monitor works in v10.0.1.0 and I'm thinking of opening a support case.
Yep - setting a scope stops that error. Clearing cache does not fix it - the error persists if no scope is set.
Seems like an issue with this MP!
can you post the full message or at least the ManagementPackClass ID in the error?
Already post on Mark comment 🙂
Ok, I am running this up the chain.
After importing this MP into our test MG, about 15% of our domain controllers are showing an error for “The total number of ATQ threads in use has exceeded one or more thresholds over multiple samples.”, but in the description it states “Failure to retrieve the raw performance data for NTDS via WMI. The error returned was: ‘Object required’ (0x1A8)”. The error can be cleared, but quickly returns, always on the same group of DCs. I can't find any particular problem on the DCs that throw this error in SCOM versus the rest which don't. A web search reveals similar errors attributed to WMI memory leaks on 2012 R2 servers that was supposedly fixed, but little else. Any ideas? Thanks.
Adam,
We have seen a similar issue in our testing but it was not related to SCOM or the MP. It was a WMI issue. In our instance the NTDS hive was not there or corrupted. Rebuilding the WMI repository resolved this issue for us.
Thanks, Eric, but when WMI is implicated, verifying the repository is my first step. 😉 These ones all came back consistent. I have noticed that vmStatsProvider seems to be taking the WMI Performance Adapter up and down constantly (machines are all virtualized), and additional research seems to indicate that if you're running another performance monitoring solution like SCOM, you might want to turn off some perfmon stuff that vmware can do, as I guess SCOM prompts it to run whenever the agent calls the mothership, or something like that. Working with the vmware guys to sort that might be a bit of a pain point, though, and I was just wondering if anyone else had solved this apparently spurious ATQ thread issue already, so I didn't have to go down that road. I know the MP hasn't been out long, but I thought I'd give it a shot. Thanks again for the suggestion.
So, what's the best solution to check or "repair"? I got this (“The total number of ATQ threads in use has exceeded one or more thresholds over multiple samples.”) after importing new MP as you. Thanks)
Did you solve this issue?
I fixed the error "The total number of ATQ threads in use has exceeded one or more thresholds over multiple samples." for the Monitor "ATQ Average Threads Monitor" after I remove the RegKey "Disable Performance Counters" in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Performance.
There were several other issues with this DC and removed the "Disable Performance Counters" for some other values as well and ran the "winmgmt /resyncperf" command. My problems were gone after this procedure and a WMI Service restart....
Adam, I was getting the same error with a quarter of my DCs. After reading the blog below, I ran LODCTR /Q:NTDS and noticed that my NTDS performance counters were missing. I checked the registry and the values under the NTDS\Performance key were indeed missing. I followed the blog, imported the missing values from a good DC, ran LODCTR /R, and restarted the health service. After some time (over ten minutes), the alert auto-cleared. I hope it works for you.
https://blogs.technet.microsoft.com/brad_rutkowski/2009/03/19/ntds-performance-counters-missing/
Hi Kevin. It looks like you will have to run HSLockdown to allow local system to run the health service, but i don't find any mention of this in the MP guide
That is because that has nothing to do with the Management Pack. That is a core SCOM agent side issue, unrelated to what MP's you might be running.
I documented the behavior here: https://blogs.technet.microsoft.com/kevinholman/2016/11/04/deploying-scom-2016-agents-to-domain-controllers-some-assembly-required/
Thank you Kevin. That explains why we did not experience this in our 2012 production environment. Will need to add this to my list of 2016 prereq's
If we still have to support 2008 R2 domain controllers, we'll still need the "old" Active Directory Server MP as well. Since that MP also supports 2012 domain controllers do you recommend disabling the "AD DC Local Discovery (DC Role)" discovery rule for 2012 and 2012 R2 servers?
If we don't, won't both sets of workflows be active for 2012 domain controllers?
If you are still supporting old 2008R2 domain controllers, I'd probably be inclined to just continue using the old MP and not use the new one until all DC's are 2012 or later.
Hi Kevin, thanks for clarifying this as I too had the same query, we basically have a mixture of 2008R2 and 2012R2 Domain Controllers and I wasn't 100% sure what best practise was on whether running both MPs together etc.
Thanks
Hi,
There is mention "action account" in management pack guide. Does it mean Agent action account which you can configure for example when installing agent or should be there separate run as profile like in previous AD MP? Can't see that kind of profile anymore with this MP.
Does this management release the need for the action account to be a domain admin in order to collect performance data, run the script or generating alerts based on security logs events?
Hi Kevin,
for the old MP is there a Custom Add: "Active Directory Server Common Library (Custom Add Ons to 6.0.7065.0) " unsealed.
This is for "Additions to make AD Discovery work with Gateways placed in untrusted AD forests"
Is this contain in the new MP 10.0.2.0 ?
In old Client Monitoring, which is now Domain Member Monitoring, I would override AD Client Update DCs rule to set one of four client monitoring modes, but I can't seem to find that option in new MP although it says global setting can be configured in Console.
Also, there are only 3 rules altogether for Active Directory Domain Member Perspective, where for old Active Directory Client Perspective we had around 30. Is this normal? There are more monitors in new one though...
Is the same set of rules/monitors infact monitoring scenarios are followed if AD is installed on Windows 2016 core version when it is monitored under SCOM 2012 R2?