Exchange Server 2013 CU2 is released

For all of who wait for a first SP before you deploy new version of Exchange Server, think again. While Microsoft will still ship Service Packs for Exchange, they also decided to go with more frequent updates, released quarterly, in order to fix most significant bugs, but also to provide new functionalities.

Yesterday, Cumulative Update 2 for Exchange Server 2013 was released, and besides fixing some known (and unknown) bugs, it provides pretty much of new and enhanced functionalities. In these areas, Microsoft has provided new or improved functionalities:

  • Per-server database support
  • OWA Redirection
  • High Availability
  • Managed Availability
  • Cmdlet Help
  • OWA Search Improvements
  • Malware Filter Rules
  • CU2 can be downloaded here: Exchange Server 2013 CU2. As before, this is full install, rather then just an incremental upgrade, but you can use it for both purposes – green field installation or upgrade of existing Exchange 2013. Microsoft still didn’t publish release notes for CU2, but pretty good overview of what’s new can be found here.

    Some tips for troubleshooting AD CS

    In last few weeks I was troubleshooting some PKI deployments, based on Windows Server 2008 and 2012, so I decided to share some troubleshooting tips from the field.

    In first case, customer deployed a Windows Server 2008 R2 Standard edition, and configure CA role on it. Since 2008 R2 supports creating and managing  of  certificate templates, there was no need to deploy Enterprise. However, attempt to install ForeFront Identity Manager 2010 R2 CA files failed, because FIM setup wizard was looking for Enterprise or Datacenter on CA. We decided to do online upgrade to Enterprise version by using dism tool and that went fine. However, from that point CA role was not able to see any custom certificate templates from AD DS, nor it was able to create new, although it was officially running Windows Server 2008 R2 Enterprise. Solution was to fix things by using ADSIEdit tool. I ran ADSIEdit and then connected to configuration partition of AD DS and opened CN=Configuration | CN=Services | CN=Public Key Services | CN=Enrollment Services. In this key, right click the problematic CA name and choose to open Properties. Switch to Attributes and look for flags attribute. For Enterprise CAs this attribute should have value 10. In my case, this value was 2. After changing this manually to 10, and restarting AD CS, everything was fine.

    In second case, customer was having huge number of failed and pending requests on his CA, as a result of improperly configured autoenrollment. We are talking about 10000+ failed or pending requests. I had to clean up this mess, and I used fairly simple method to do this. If you execute this command:

    certutil –deleterow 01/06/2013 Request,

    as a result all pending and failed requests generated before June 1st 2013 will be deleted. Be aware however that this command can clean up around 2500 rows in one pass. If you have more requests to clean, command will throw an error after it’s done. Don’t worry about that, just re-run this same command few times, until all is cleaned up.

    Similar, if you have large number of expired certificates in your Issued certificate store on CA, you can use similar command to clean them up. Execute:

    certutil –deleterow 01/06/2013 Cert,

    and all certificates expired up to June 1st 2013, will be deleted.

    And if you need to delete some specific request, make sure that you find appropriate requestID and execute this :

    certutil –deleterow RequestID.

    After you clean up the mess on the CA, it’s a good idea to defrag the CA database. Same utility as for AD DS DB defrag is used, which is eseutil. Just run eseutil /d pathtoCAdbfile.