USB KVM RFI: Final Followup

This, I hope, is the final followup to my USB KVM interference problemI thought I had fixed it, but no.  That decorative nameplate was indeed just decorative.

I tightened all the screws on my Tyan server board and the problem seems to have disappeared.  The nameplate on the KVM fell off, again, so out with the hot-melt glue gun.

Advertisements

My Overflowing Workbench

I’ve had to put aside my home electronics activities for a long time due to nearly losing my eyesight several years ago.  While things are better for me now, it’s high time I took advantage of my long-time love of electronics and technology.  This is my workbench.  It’s cluttered but before I cleaned it for a house inspection, it was much worse.

Tools.  The small box at the lower left had the cabling tools I used at SATV.

Some of my test equipment.  You may have seen the small Triplett DMM on my workbench.  Here is a decibel meter, a Kill-A-Watt, and in the reused Norelco pouch, a Bus Pirate (a very useful tool for connecting to serial buses.)

And I have a scope cart.

The scope and frequency counter work—the scope is a HP 1722 with good 275 MHz bandwidth.  The counter only does 60 MHz so I’ll need a new one for my ham radio work.  (Someday)  The DMM at the bottom is a sick HP 3440—it has a broken switch in the signal path, but I do expect it to be fixable.

A collection of microcontroller development kits.  One Z8 Encore I played with and bought at ESC some years ago, and three MSP 430’s, one of which is a wireless module.

I never had time to really use them.  I really got into the Z8, but when I looked into getting a network stack for it I had sticker shock.  I could really use a Ethernet module such as the Spinneret Web Server coupled with an cheap GPS module.  SATV has wanted a GPS NTP source for a very long time.  I’d like to be able to get the Ethernet and controller for less than $50 with a network stack and a toolchain (compiler/linker/debugger) that goes well with my Windows background. 

I even have a “new” 12V worklight, of sorts:

It’s the lamp from one of my old broken scanners.  It works.  The hardest part will be building an enclosure.  I never have enough lights.

I’m just glad to be tinkering again.


Resolving “PAUTOENR.DLL raised an exception”

This has been nagging me for about a month.  On my personal SBS 2008 box, since mid-October, I have been getting this error repeatedly.  When logged on to the server console, a Windows Error Reporting dialog pops up every minute reporting that Taskeng.exe has stopped working.

Taskeng is the main process of Windows Task Manager, which has a console under Administrative Tools. 

What was causing Task Scheduler to crash?  I very quickly found it—Certificate Services Client was causing it, as you may have seen in the Event Viewer screenshot;  it throws a error message right before Task Scheduler reports the crash.  It has three tasks:  SystemTask, UserTask and UserTask-Roam.  On my machine, SystemTask was crashing and trying to restart.  That accounted for the repeating WER dialogs.

But what is the Certificate Services Client?  What do its three tasks do?

The Certificate Services Client (CSC, not to be confused with Client-Side Caching) is a component of Windows that allows users to use their site certificates, which are often used for VPN, email authentication and many other services on a corporate network.  It’s been a part of Windows for awhile, and it’s on Windows Server 2008 and by extension SBS 2008.

A very important part of the CSC is autoenrollment:  Autoenrollment is the process of keeping track of user certificates, expiring them and renewing them as needed.  PAUTOENR.DLL is the DLL that manages this process, running with DIMSJOB.DLL and DIMSROAM.DLL under Task Scheduler.

After a lot of tracing with Process Monitor and a lot of research online, I have a conclusion:  The CSC, and the Autoenrollment feature, each keep a cache of certificate information.  It was corrupted.   I suspect a certificate expired sometime in October or a bit before, and the Autoenrollment choked on it.

I must note at this point that the CSC is a client.  On an SBS machine, it runs alongside the Certificate Services role, but it is totally separate so it does no good to troubleshoot Cert Services if it is otherwise working.  Don’t touch Cert Services.

This is an involved process with several reboots so you will need patience.

  1. First, pull up Task Scheduler from Administrative Tools.  Select “Task Scheduler Library” and open Microsoft\Windows\CertificateServicesClient.   We are going to disable each of the three tasks before we delete the cache.  On each task, SystemTask, UserTask and UserTask-Roam, right-click and select End.  Repeat this for each task and select Disabled.
  2. Follow these steps to delete the certificate cache on the server:  Go to the LOCAL SYSTEM profile at C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache.  Copy the CryptNetURLCache folder to a safe place.  Two folders are there—Content and Metadata.   Go to each folder and delete the files therein—don’t delete the Content and Metadata folders themselves.
  3. Run Regedit as an administrator and go to this key, HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\AuthRoot\Certificates.  Delete all the keys under this key.   That takes care of the certificate cache.
  4. Now, delete the Autoenrollment cache.  Go to Regedit and to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache.  Delete all the keys under that key.
  5. Go back to Task Scheduler.  Open the CertificateServicesClient folder that we had opened before (Task Scheduler Library\Microsoft\Windows\CertificateServicesClient).  Right-click on each task and select “Enable”.
  6. We aren’t done yet.  The Certificate caches have been empty, but they need to be repopulated.  To do this, we need to change the local security policy on the machine to turn on autoenrollment temporarily until the caches are repopulated.  By default (on my SBS box at least), autoenrollment is not turned on.  This is often done on Windows networks via the Default Domain policy but I am really uneasy about making a global change to fix a local problem so the local security policy is the best way.
  7. Open secpol.msc as an administrator to access the local security policy.  Click on Public Key Policies.  On the right pane, double-click Certificate Services Client—Auto-Enrollment Policies.  In the dialog, click on the Configuration Model dropdown box and select Enabled.  There are two checkboxes:  Check both boxes, “Renew expired certificates, update pending certificates and remove revoked certificates” and “Update certificates that use certificate templates”.  Click OK.
  8. From an elevated command prompt, enter the command gpupdate /force to make the change apply to the machine.
  9. Restart the server.
  10. Log back on and reopen the Task Scheduler and the CertificateServicesClient task.  SystemTask and UserTask will show as running.  Click on SystemTask, and click the History tab.  The most recent events in History should show that the task started normally and is currently running.
  11. While still on the SystemTask window, right-click and select End.  This task normally only runs when the system is restarted, and every eight hours thereafter.
  12. Next, we will undo our changes to the local security policy.  Open secpol.msc as an administrator and select Public Key Policies.  Click on Certificate Services Client—Auto-Enrollment Policies.  On the Configuration Model dropdown box, select “Not Configured” and click OK.
  13. From an elevated command prompt, reenter gpupdate /force to undo the change.
  14. Restart the server again.
  15. Log back on once again and reopen the CertificateServicesClient task.  SystemTask should be listed as Ready or Running.  UserTask should be Running.  UserTask-Roam should be Ready.  Look at the event history for each task.  If there are no errors since the last reboot, the problem is resolved.  You may want to try running the SystemTask as a test, if it is not already running.