System Log – 36886 – No suitable default server credential exists on this system

I have a DC that has been getting theses errors every 25 minutes for some time now. They show up in DCDiag, which is why i was so concerned in the first place. These errors would indicate installing a CA is the way to go. That is th stupidest idea I have ever heard. You don’t install a component like a CA just to fix an error you don’t understand.

The long and short? The Loglogic application caused these and I don’t really know why. But packet sniffs bear it out.

Starting test: SystemLog
A warning event occurred. EventID: 0x00009016
Time Generated: 03/22/2020 06:51:59
Event String:
No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this.

With password being changed, I was afraid this was something that would impede logins. But, testing showed logins ok. After digging more, I found that this specific error also shows in event viewer.

More research showed that the error can indicate the lack of a Certification Authority in the AD. This is not the case here. PPS has never had a CA and never have gotten these errors in the recent past. In EV, it shows as a 36886 SChannel error.

This google shows what you get when you look for this error

Extensive research did not show any other possibilities so wireshark was employed to determine what the issue is. Analysis showed that the server causing the issue is the Logic Monitor server, PPSMON01, a server which curiously will not back up. I did captures on PPSAD01, and PPSAD03. They show this RST event at the exact time the error occurs in EV on that server.

Since this is a physical Dell server, and older as well, I have updated the BIOS, Firmware, Chipset and other hardware components from Dell’s support downloads. Four updates total.

This did not fix the issue.

So now I know that the machine is MON01 but I don’t know what about it is doing that. All of the updates (especially BIOS and NIC firmware) did not have an expected result. To be sure, I went to MON01 ( and stopped the service right before the event was expected to happen, about 25 minutes apart. It did not happen when the Loglogic services were stopped, so, something about Loglogic is causing this.

Find which servers are sending SMTP Traffic

I have a big project migrating email from an on-premise server to Office 365. The Exchange environment has been around for almost 2 decades and many applications route email throught Exchange.

I needed a way to find who is sending. So, I used LogParser 2.2 (Microsoft) to analyze the SMTP logs.

Take the code below, after installing LogParser, and run it in the directory where the SMTP logs are located. In my case, you can see it below.

The program will simply read all of the logs in the area where it is run from. You wind up with the results below. Perfect!

*** If you copy and paste this code, make sure that the single and double quotes are correct as WP seems to make them different than the normal ASCII text***

“C:\Program Files (x86)\Log Parser 2.2\logparser.exe” “SELECT EXTRACT_PREFIX(remote-endpoint,0,’:’) as IP,REVERSEDNS(EXTRACT_PREFIX(remote-endpoint,0,’:’)) as Name,Count(*) as Hits from *.log WHERE data LIKE ‘%EHLO%’ GROUP BY IP ORDER BY Hits DESC” -i:CSV -nSkipLines:4 -rtp:-1 – This one has the query above.

Using Log Parser and Protocol Logs to Analyze Send Connector Usage

VSSADMIN Blocked by Group Policy – Server 2019

I have a 2019 server standard that was giving me this error from an elevated CMD

This program is blocked by group policy. For more information, contact your system administrator.

This kept me from viewing the state of the writers and troubleshooting a Datto backup issue.

This is the specific error seen in the application log:

Access to C:WindowsSystem32vssadmin.exe has been restricted by your Administrator by location with policy rule {e9e0e074-bb50-497a-8b0e-f357a16a3e4d} placed on path vssadmin.exe.

This led me to this article:

I went to the Local Security Policy and exanded to the path below

I created a PATH rule that allowed the specific exe to run. THEN, the magic happened. The server informed me that the default rules for the server had not been created. Would I like to create them now? I said yes, and the three default rules appeared with my new one! Now it works!!!

vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp.

Error: Invalid command.

—- Commands Supported —-

Add ShadowStorage – Add a new volume shadow copy storage association
Create Shadow – Create a new volume shadow copy
Delete Shadows – Delete volume shadow copies
Delete ShadowStorage – Delete volume shadow copy storage associations
List Providers – List registered volume shadow copy providers
List Shadows – List existing volume shadow copies
List ShadowStorage – List volume shadow copy storage associations
List Volumes – List volumes eligible for shadow copies
List Writers – List subscribed volume shadow copy writers
Resize ShadowStorage – Resize a volume shadow copy storage association
Revert Shadow – Revert a volume to a shadow copy
Query Reverts – Query the progress of in-progress revert operations.

ADMX Files and the Central Store

This guy’s short video is the best no nonsense summary of what to do with new ADMX files.

In short, always overwrite any admx files with ones you KNOW are newer because they are named for the technology affected by the file. So newer is alway better. And if you copy one in and there is no overwrite? You now have totally new features to play with. Look at the XLSL file in the ADMX Zip files.

Migrate FRS to DFS

I had a client recently who has all 2008 DCs and wanted to introduce 2016 DCs. No big deal. Prep the domain and forest and off you go. Except that this client was running in 2003 forest mode. And that led to a different discovery: FRS was being used for SYSVOL/NETLOGON replication. And this is not going

Image result for frs to dfsr

to cut it in a modern AD. Migrating is not especially difficult but it requires a little know how, patience and perserverance.

This article by Patrick van den Born was a wonderful resource that had almost all that I needed to get the pieces in place.

*** Make sure to install DFS on all the 2008 DCs but do not create a namespace. – also good!

Test replication by going to the “scripts” folder in SYSVOL, adding a text file, and making sure that it IMMEDIATELY appears in all the other DCs’ Scripts folder.

Exchange 2016 Tracking Log Searches

Exchange 2010 was the last iteration that included a decent message tracking log interface. Microsoft intentionally broke that wonder search app with 2013 in order to push admins to use powershell. So, when I had to track down the internal source of an email that was being sent by a job that did not appear to exist (we have dozens of applications that route mail through Exchange) I had to use PowerShell to track down the source IP.

Image result for exchange powershell


This proved not to be the easiest thing to do. I was not sure where the original source IP even resided. So, I decided to start with everything for the first query and work my way back from there. I also decided to use the wonderful | Out-Gridview feature to pipe the output to a GUI so that I could filter from there.

Here is the query to use:

Get-MessageTrackingLog -Server mail01 -Start “Aug 7 2017” -sender “” -resultsize unlimited | select-object TransportTrafficType,SchemaVersion,RunspaceId,Timestamp,ClientIp,ClientHostname,





TenantId,OriginalClientIp,MessageInfo,MessageLatency,MessageLatencyType | Out-Gridview


This gave me the information that I needed. Too much information in fact, which was easily remedied by the Out-View Grid’s “Add Criteria” feature. In the end, it was the OriginalClientIP field that gave me what I needed!