JasonSamuel.com

You can use OpenSSL and run this command:

openssl.exe s_client -connect www.mysite.com:443

which will use a generic SSL/TLS client to connect to your site and give you a ton of diagnostic info.  You can see your entire SSL cert chain, the SSL handshake, SSL session info, etc.  Here’s a full list of switches you can use with it:  http://www.openssl.org/docs/apps/s_client.html

And here’s a great online tool to graphically verify your SSL chain is intact:  http://www.sslshopper.com/ssl-checker.html

By default, most applications write events to the Application Event Log.  This is a great central place to write logs to but sometimes you might have a requirement to log informational events from an application and you don’t want it filling up your Application Event Log because of the sheer number of informational events you might get a short period of time.  The solution is to create a custom event log for your application to hold these events.  You can then set max log size, overwrite rules, filters, etc. on this event log while your Application Event Log remains clean and intact.

The first step is to create the new log.  You have to do this in the registry.  Open up regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog

Right click on the Eventlog key and click New > Key

Name this new key the same name you want your new event log to be named.  By default it will create the new .evt file here:

C:\WINDOWS\System32\Config\New Key #1.evt

You can always rename it by editing the string value data in the registry if you like.

Now you need to add Sources to your new event log.  Right click in the right window pane under your new key and add a new Multi-String value called “Sources” and add the name of each of your applications on each line.  It should look something like this:

Now you need to move the association of your application from the Application event log to your new Custom log.  Just expand the “Application” key located at:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\Application

and copy whatever key you see in there for your app under your new Custom log:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Eventlog\CustomLog

There’s no copy/paste command so you can recreate the key if it’s small or you can export/import if it’s something complicated and you are afraid of mistyping something.  MAKE SURE to delete it from Application after you add it to the Custom log or it will not write events to your new log since Windows thinks its still associated with the Application log.  If it is a custom source, you need to create a DWORD value under this key with the value of 1:

You will also notice my custom app in this example is a .NET 2.0 appliaction so I want .NET to write the events to the log.  I have to create a string value called EventMessageFile and give it the path to the .NET 2.0 event log message dll:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll

Now you should reboot your server.  When it’s back up, check and see if your new event log appears under Event Viewer.  If your application is not writing events to your new log, test it manually by opening a command prompt and going to:

C:\WINDOWS\system32

and typing:

eventcreate /l CustomLog /t Information /so Application1 /id 1 /d “Test message”

You should get a message saying it was successfully written or you should get an error message with details on why it was not written.  If you followed the steps in this blog post, it should write the event just fine.

If you’ve ever used Urchin 6 for web analytics (Google’s pay for version of Google Analytics aimed at enterprises), you have probably seen profiles stuck in a “Running” state.  If you hit Run Now, you get this error message:

12008 – Action: Failed to cancel urchin process.

If you try to reschedule the profile, you get this error message:

12007 – Action: Failed to add profile to the scheduler queue. The profile is already in the queue.

This happens because Urchin’s scheduler is very sensitive to server reboots.  If you have jobs scheduled to run at night and let’s say you push patches to the server and reboot in the middle of the night, it can cause this error to appear on some of your profiles.  You get these errors because the log processing engine and scheduler never received the proper exit signals which means there will be database entries in the MySQL database that will be in an inconsistent state.  When the server boots back up, the log processing engine cannot pick back up where it stopped and the web GUI will show the profile is “Running” even though it is not.

The quick solution for this is to navigate to your Urchin bin folder via command prompt.  Here is an example path:

C:\Program Files\Urchin6\bin

then type:

urchinctl stop

which will stop all Urchin processes.  Then open up MySQL Command Line Client and type:

use urchin;
delete from uprofiles_queue;

This switches the database to the urchin database and deletes all running profiles.  Now if you go to to the web GUI under Profile Task Scheduler, you will see everything looks normal.  Now trying running the job again and it should work.  You should get a message saying:

12009 – Action: Profile has been queued to run. Please check the Profile Task History screen for status and runtime output.

Now don’t forget to restart your Master and Slave scheduler services or the job will remain in a queued state until they are back up:

urchinctl start

Now verify the job is actually running properly by clicking the green “Running” link for the job and you should see it processing the logs.

.NET 2.0 counters won’t show up in perfmon by default when using the /wmi switch.  They will show up in you just use regular perfmon but if you are trying to monitor .NET 2.0 counters via WMI, you are stuck.  Microsoft is aware of this and released 951683 to fix this issue.  You can request the hotfix from CSS here:

http://support.microsoft.com/kb/951683

This hotfix is included with .NET 3.5 SP1 onward so if you have it installed, you shouldn’t experience this issue.  After installing the hotfix (does not require a reboot), just restart the WMI service and run this from command line:

winmgmt /resyncperf

which will resync counters with WMI.  Then open perfmon using “perfmon /wmi”  and you will see the missing counters. 

You can also use the wbemtest.exe utility to test and troubleshoot WMI related issues.  Just run this from command line:

wbemtest.exe

Click the Connect button and change the very first field to “root\cimv2″.  Then press Connect and then click Enum Classes on the next window.  Leave the superclass blank but change it to Recursive and press OK.  It will query every WMI class on the server and you can click on them to get further details.  This should help you tremendously if you write your own WQL queries!

You can install pretty much any windows component locally or remotely on a server.  Here is an example of installing SNMP using an answer file via command line locally on a server:

sysocmgr /i:%windir%\inf\sysoc.inf /u:”\\server\share\snmp.txt” /q

This will install SNMP quietly using the answer file I give it which is located on a file share.  Here are the contents of the answer file:

[NetOptionalComponents]
SNMP = 1

[SNMP]

Send_Authentication = Yes
Accept_CommunityName = mine_ro:Read_Only
Any_Host = No
Limit_Host = xxx.xxx.xxx.xxx

This will automatically configure a new read only community you specify and add a single host that is allowed to connect (you can add more IPs but adding a comma after each one).  The only dilemma is that during the install, it needs to get at the i386 directory and by default in the registry, it is pointed to “D:/i386” more than likely since that is typically the CD-ROM drive you installed the OS from.  We just need to run a quick registry update to two keys that point it to the C: drive before running the line above and it should work with no issue.  This can be done in bulk on servers too using whatever remote management tool you prefer:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\Sourcepath

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows \CurrentVersion\Setup\Sourcepath

Keep in mind sysocmgr.exe has been replaced in Server 2008 by ocsetup.exe.  You can read up on command line switches for it here:

http://technet.microsoft.com/en-us/magazine/dd673656.aspx
http://technet.microsoft.com/en-us/library/cc766272(WS.10).aspx

Today I would like to clear up some confusion about SSL Chained Certificates. For this example, I will use Network Solutions as the Certificate Authority (CA) you are buying the cert from. This is information you will have to know when you purchase a new SSL cert or renew an existing SSL cert for your Exchange server, IIS web server, or any other external facing server or appliance.

Network Solutions does not issue you a single cert. They issue you an SSL chained cert. So for example, if you are buying a cert for:

widgets.com

They will validate and issue you the cert, but when you download and open the zip file from their website, you will see the following certificate bundle:

AddTrustExternalCARoot.crt
NetworkSolutions_CA.crt
WIDGETS.COM.crt
UTNAddTrustServer_CA.crt

Let’s analyze these certs in your chain. The first one is AddTrustExternalCARoot.crt which is called the “root certificate”. This is the first cert in your chain. This root cert is installed to the Trusted Root Certification Authorities store on your server or network appliance.

The second cert in your chain is NetworkSolutions_CA.crt and the UTNAddTrustServer_CA.crt which are “intermediate certificates”. An intermediate cert is essentially a certificate issued by the Trusted Root CA specifically designed to issue SSL Certificates to you. The reason for this is because if the CA root cert were to ever be compromised, the entire chain fails. It is good security practice to use an “intermediary” to issue the certs from to prevent your root CAs from being exposed from the signing process. If an intermediate were to ever be compromised, you can always regenerate those unlike the root certs. This intermediate certificate sits between your website cert and the root cert. This intermediate cert is installed to the Intermediate Certification Authorities store on your server or appliance.

The last cert in your chain is WIDGETS.COM.crt which is your actual SSL cert. This is also known as your “domain certificate”. This domain cert is installed to the Personal store on your server or appliance.

So the end result is chain of certs that begins at the trusted root CA, runs through the intermediary, and finally ends with the SSL certificate issued to you for your website or appliance (widgets.com).

In most cases, any sever or appliance out there will already have the trusted root cert for Network Solutions installed. You can just install your SSL cert and not have to worry about anything else in most cases. Depending on where you buy your cert from and what you are trying to install your cert to, you may have to go through the steps of installing the Trusted Root cert and Intermediate cert first before installing your SSL cert. With some web browsers like Internet Explorer 7 for example, you can get away with not having to install any Intermediate Certificate because IE7 will automatically go out automatically download the intermediate cert the first time a user visits your website. This makes things easy for the lazy admin but it’s always best practice to go a head and add the Intermediate cert on your end instead of depending on the client and their browser’s ability to do this. There is no point in risking a certificate error for the end user when the fix is so easy.

To verify the chain, go to any site you know that uses SSL (https://) and then click on the lock in Internet Explorer, it will let you view the SSL cert info. Click the “Certificate Path” tab and you can see the chain we described above:

Trusted Root —> Intermediate —> SSL Certificate

You can then click on each one of these certs and hit the “View Cert” button to view each cert in the chain individually. Good luck and post a comment if you have any questions.