Problems with Exchange 2010 updates

In a recent post, I mentioned a problem with an endpoint mapper (RPC) after the installation of Service Pack 2 for Exchange 2010. It has come to my attention that the reason for this problem is due to a problem with the initial installation. The problem happened again in the same Exchange environment during a Rollup 2 installation which lead me to investigate the Exchange Setup logs further. In the file UpdateCAS.log the following entry was logged.

The line reads "Error updating OWA/ECP: The term 'Get-ExchangeServer' is not..." which indicated a problem with the Exchange Management Shell (PowerShell) commands. After browsing around the configuration I noticed that some entries were missing from the registry compared to another Exchange server.

A quick fix for this problem was simply to export the PowerShellSnapIns key from a working Exchange server and import the difference to the faulty one. The question to why these keys are missing in the first place still remains unanswered. However, we're one step closer to the truth.

Excessive login time in Windows 7

I recently stumbled upon a client where the login time could be classified as not of this world. For me, any login time exceeding 10 seconds is to be considered too long. I'm not talking about boot-up time but the time it takes for the desktop to appear after username and password has been entered. After the usual investigation relating to the network, DNS and Group Policies, the problem was found in the event logs.

Say hello to nearly 4 minutes of Folder Redirection processing. As it turned out, the user had made its entire home folder available offline which caused these dramatic effects to the login time as the number of files exceeded too many to be mentioned here. The solution was simply to not make the files available offline and clear the temporary cache which decreased the login time to a respectable 5 seconds.

Certificate request from an OS X Lion client

It appears that Apple has made it quite convenient to request a certificate from a Windows Certificate Authority using the AD Certificate Payload Plugin. There are a number of issues that needs to be addressed however but in the whole it seems to work fine. This method actually makes it possible for the OS X client to acquire a computer certificate used for 802.1x authentication in a very slick procedure without the usual hands-on intervention by a network technician. My next quest is to develop a similar method for the not so domain-joined devices known as iPads/iPhones. I'm leaning towards a solution involving the old NDES/SCEP service to bring clarity and justice for all.

The shell of the youth

So what shell are the kids of today using. Bash? Well, not according to my 4-year old son. Lo and behold...

Yes, that's right. PowerShell is the shell of the youth and the future. At least in my part of the universe.