Event 10036, DistributedCOM

Comes here often

Event 10036, DistributedCOM



Have an error that just started occurring last Tuesday, September 14th after updating my domain controllers. I'm getting the following error; 


The server-side authentication level policy does not allow the user domain\user SID (X-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXX-XXXXX) from address to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.


The IP address ( is my MX IP Address. This error I believe has to do with Active Directory Authentication I have set up under Security & SD-WAN Active Directory. I'm getting the same error for all 3 sites each pointing to the IP address of the MX device. The error occurs roughly every 2 hours in my event log on my domain controllers.


In my test network, I disabled Active Directory Authentication on that MX and the errors stopped. I have googled my heart out for Event 10036, DistributedCOM, and can't find anything related to the above error. I did find one someone on Reddit who experienced the same issue but it was on a Palo Alto firewall. 


Does anyone else have this happen since last week's patch Tuesday? I'm not even sure how I would go about raising the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.


Everything works fine and users can still login into the client VPN using their AD credentials. But, this error is really strange and is filling up my event logs. 


When I run a dcdiag everything passes, but the error shows up under SystemLog


Could this be a possible bug? 



I just noticed this error this morning while looking for another issue. 

Just browsing

Having the same issue. I raised the authentication level to Packet Integrity on a Server 2016 DC, rebooted and errors still present.

Checked my MX device and had a generic WMI error that referenced setting up MX device to authenticate to AD.


Configuring Active Directory with MX Security Appliances - Cisco Meraki


Read the link a bit and went back to the device and error is no longer present.


Looking into it further tomorrow. Will update if any progress.

Comes here often

I get those WMI errors on my MX every so often. I believe this is on MS to resolve and hopefully address the issue soon. No impact to my AD authentication because of the error, it's just really annoying seeing it fill up my event log. 

New here

Hi! I've seen this error attributed to the September update - KB5005568: 




Comes here often

Thanks for this link, ALibraian. I will continue to monitor that post and see if anyone comes up with a solution. I've tried a number of fixes for this and have come up empty. 

New here


Do you have any update for this ? We have the same problem.

Best regards

I have not found a solution other then uninstalling the Windows update.




It's not a solution.

Meraki doesn't do anything, it's incredible.

Best regards

New here

Same here. This is on Meraki and Microsoft to work out.

Comes here often

I would have to agree. I’ve tried numerous work arounds to try and get the error to stop and turning off AD authentication is not the answer. This has been going on for months now and other than clogging up my event logs on my DCs I still haven’t noticed any negative impact. 

Comes here often

Any update on this issue or is Meraki just pretending it doesn't exist?

Just browsing

Have this same issue and resolve?

Here to help

Following this as we've been experiencing this issue since deploying our Windows Server 2022 DC's. Hopefully Meraki engineering eventually figures this out. 

Here to help
Comes here often

I have fixed this issue in our setup. Same error. Turns out that the Active Directory authentication done by the MX box requires TLS. For that, the chatter uses an SSL certificate. I had just finished replacing our DC with a newer box. Since it was only being used as a DNS server, only the barebones installation was done. As you, I panicked a bit when I saw the errors fill up the event log. After sleuthing around and reading posts everywhere, ya'lls reminded me about the active directory link with the MX box. Checking on it, the console reported the error where it could not authenticate with the new DC. Reading the requirements for this setup, I found that it needed an SSL certificate. I installed the IIS role and created a self-signed cert. Once that was done, the MX was able to connect and when I checked the server's event log, the messages no longer appeared. Hope this helps! 

Thanks for your feedback. It is an option and also setup AD as Certificate Manager. Is really good to know we are solving this becasue if we wait for Meraki support  it wil takes ages....

Comes here often

My DCs have certs that are automatically issued from my internal Windows Server CA, but I think the subject name is the DNS hostname of my DC, and there are no IP address SANs on the certs. In order for the certs to work correctly, I think the Meraki needs to connect to the DC's via hostname and not IP address? I'm wondering if that's my issue? If I replace the IP address with the DNS name in the Meraki admin portal, it gives me an error that it's an invalid server IP. I also am not seeing where I can specify an internal DNS server in the Meraki admin portal so it can resolve the DNS name. Am I missing something?

I connected them with IP address. The key is create an local user on AD server with WMI read only options. Let me atach here the steps that I followed:


1. Create and account in AD enrolled in Domain Users and Account Operator domain groups. In this case account is: usrmeraki (this an example name)


2. Setup AD CS as follow: https://dinika-15.medium.com/installing-active-directory-certificate-services-ad-cs-4db7d0950289


3. Create a certificate for Domain Server to permit Client Authentication and Server Authentication opening manage Computer Certificates: certlm (run comand in CLI as administrator)


4. Expand Personal and over Certificates, right clic and request a new certificate, follow the wizard and check

Domain Controller Authentication and then click on Enroll.


5. Validate new certiifcate is created in: certlm (run comand in CLI as administrator)


6.  Grant WMI acces under root\cimv2 usrmeraki account in AD Server as follow

WMI Control --> Security (tab) --> CIMV2 (tehn click on security button)

Add user usrmeraki and enable: Enable Account and remote Enable


7. Grand Permission over DCOM components AD Server as follow: dcomcnfg (run comand in CLI as administrator) 

Right Click on My Computer (Left Panel) selct propertties. Go to COM Security (tab)

In Access permision: add usrmeraki with Local Access and Remote Access

In Launch and Activation Permissions: add usrmeraki with Local Access and Remote Access


8. Go to Open Meraki web console and test credentials under active directory menu  and test conectity and read groups/users you want to include in MX device. Fill boxes as follow:

Short domain: yourdomain.com

Server IP: IP Address for AD Server

Domain admin: YOURDOMAIN\usrmeraki

Password: Your Password


9. With this conifugration you will see green check on status and integration is working as expected.


Hope this helps you 🙂

Do you have look?

Comes here often

All -

The 16.16.3 firmware resolves the 10036 DCOM  issue.

Hi, this update don't fixed it. Trust me.

Comes here often

Meraki has not released an update to resolve this. The only solution for me was to disable the authentication level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation.


This method will only work until March 14, 2023. Then Microsoft will enforce it with no way to disable it.


You can find the article here;

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) 

Is the same, it not works, believe me. The only thing worked for me, I published above.

16.16.3 firmware reduces the number of DCOM errors in the logs but does not resolve the issue. I spoke with Meraki support this week, and they acknowledged this as a known issue. The devs are supposedly working on this. In the meantime, their recommendation was to set the reg key as per the MS article mentioned earlier.

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft...

Here to help

I'm on MX 17.8... and nothing changes, from my view.


almost a year later and this is still an issue ..... ?


please tell me someone has a fix for this.

Hi, try with comment above on date: ‎06-22-2022 12:50 PM . Hope it can helps.


This continues to be an issue, we cant upgrade our domain controllers to server 2022 because the regfix that microsoft recommends doesnt work on server 2022. We are also now starting to get sporadic issues with the firewalls not picking up the correct user information as well as high CPU usage on our DC's. Meraki support don't seem to have any idea when the developers are actually going to fix this, and ive had a ticket in about it for 6 months. astoundingly poor considering if it doesn't work then our entire capability to safeguard staff and students doesn't work as we rely on applying policies based on staff/student group memberships and then applying to devices based on who is logged in.


What's even worse is that this area of policy application even when working doesn't actually show in the client list of devices, only in event logs, which is frankly the dumbest design decision I have ever seen for what is generally a really well designed dashboard. I need to be able to see what policy is applied to a device from the client list not trawl through event logs to see.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.