The first preview of Microsoft's new Operating System, internaly codenamed "Windows 8" by Julie Larson-Green, Corporate Vice President, Windows Experience.
A couple of weeks back, a certificate was approaching it's expiration date on an IIS server and the update - although pretty straight forward, caused a major issue for the service running on that server. I had the new certificate in PFX format, I've installed it on the computer certificate store and it was available in the IIS Manager console. All the certificates for the Root and Intermediate authorities were property installed and the clients had access to the CRL urls. However, when I switched the certificate, the clients were not able to communicate property with the website. After going through the logs on the clients and the application, I discovered that the clients were using client certificates in order to authenticate and the validation process was failing for those certificates since my server could not check their revocation. I opened up a command prompt to get more information on the bindings on the website since there are settings that are not available when...
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute: repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your...
I run across a very strange issue a few days ago and I feel that I should share it with you since it took me some time to figure it out! Some Exchange servers had stopped recording events in the Security log. The first thing that crossed my mind was to check the latest event in the Security log that would probably be the event regarding the audit policy change. I was correct, there were many events with id 4719 that showed that the policy had been changed. The next step would be to update the policy in order to enable auditing. There were servers that had auditing configured according the security baseline so I backed up the auditing configuration from one of them using the command: auditpol /backup /file:C:\Temp\Audit.txt Next I copied the file to the server with the issue and used the command: auditpol /restore /file:C:\Temp\Audit.txt to restore the settings. The command completed successfully and it was time to check the new auditing settings. For this I used the com...