SSL security and Microsoft Exchange

This year the SSL Certificate Authorities announced that they would no longer be allowing SSL certificates to be issued for private IP and internal domain names. In my company this meant that when our SSL certificate recently expired we could no longer renew it for the internal exchange server name (exchange.domain.local). This was all well and good for OWA and our external staff who used our external domain address in their email clients, but it caused Outlook to have a major hissy fit and complain that the SSL certificate wasn’t valid and kept popping up an annoying warning message.

So off I went to hunt down a solution to the problem. There were two main suggestions that permeated throughout the internet:

1. Map the internal server name to the matching external name by setting up new DNS zones on the domain controller.
2. Changing the Exchange server to user external DNS names.

Option number 1 didn’t work properly for me. It was probably a configuration fault on my part as others have reported success with that approach. However, it is kind of cumbersome as you have to create a new DNS zone for each external address (you’ll need at least two – server.domain.com and autodiscover.domain.com).

Option 2 however was far more successful. Using a guide provided online by Digicert I discovered that using the Exchange Management Shell on the server, there are three Exchange entries that you need to change with the following commands:

• Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml
• Set-WebServicesVirtualDirectory -Identity "HostName\EWS (Default Web Site)" -InternalUrl https://mail.yourdomain.com/ews/exchange.asmx
• Set-OABVirtualDirectory -Identity "HostName\oab (Default Web Site)" -InternalUrl https://mail.yourdomain.com/oab

Once you have run these commands in Exchange Management Shell on the server, you need to then open IIS Manager, expand Application Pools, right click on MSExchangeAutodiscoverAppPool and then choose the Recycle option.

Once you’ve done this Outlook will no longer complain about invalid SSL certificates.

Remote Desktop goes black after login

When trying to login remotely to a server today I discovered that on every attempt, when I was redirected from a successful login to the desktop, the screen would go black and be unresponsive. The server was running fine and the login worked fine from the console. After a bit of searching I discovered a thread on the Microsoft Technet forums discussing this very issue.

The solution to this problem was very simple but completely unexpected. By pressing CTRL + ALT + END I could trigger the Windows security screen (much like CTRL + ATL + DEL does on a local computer). Pressing cancel on this box then restored my desktop on the server.

Others have reported online having to take an extra step of disconnecting their RDP session and then reconnecting again in order to fully restore the desktop. Many thanks to Rob Kraft on the Technet forums for this deliciously simple solution.

CUPS configuration - Be careful what you do!

So having moved from a piecemeal Ubuntu server solution to Zentyal for my home server, the one last thing I'm having trouble setting up is printer sharing. There seems to be three ways to do it; via the printers app, on the Zentyal console or via the CUPS webpage. It turns out the correct way to setup a printer for Zentyal to share is via the CUPS route.

This was all well and good, and I eventually worked out how to setup my printer and share it. But I made one schoolboy error and ticked the Kerberos authentication box. When I tried to reconnect to the CUPS webpage all I got was an unauthorised access page and no login box. There was no way for me to get back into the web config to fix the problem. This seems to be a bit of bug that needs addressing but I suppose common sense prevails and not ticking boxes without knowing the outcome is probably the best way forward. We can't wrap everyone in bubblewrap and even us IT guys need to exercise caution at times!

Fortunately it turns out that if you find yourself in this situation, all you need to do is log onto the server and replace the /etc/cups/cupsd.conf file with the default file. If you can't find the default file (like me) then just copy the text from another file or the internet and paste it into your cupsd.conf file.

To save you lots of further hunting, the original cupsd.conf file content can be found on answers.launchpad.net courtesy of the user actionparsnip. Thanks fella!

XRDP and Zentyal Server

Due to a... ahem... user error recently, I've found myself in a position to rebuild by home server. So I decided to go back and give Zentyal a try as it looks like its improved a lot since I last tried it out. Configuration of the server so far has been a breeze and the amount of documentation provided by the team and community at Zentyal is fantastic.

However I wanted to do one thing that was documented and setup remote access to the server. I know that pretty much everything can be done through a browser, but my home server isn't attached to a keyboard or monitor, so I like to have a way of getting into the server to troubleshoot. My software of choice is XRDP as I've used it all before and it works like a charm.

Unfortunately, this time it didn't quite go as smoothly as previous experiences. I'd managed to setup the port access on the Zentyal firewall and my RDP client could remote to the correct ports, but internal routing from the RDP service to the internal VNC server wasn't working. I kept getting this error:

connecting to sesman ip 127.0.0.1 port 3350
sesman connect ok
sending login info to session manager, please wait...
xrdp_mm_process_login_response: login successful for display
started connecting
connecting to 127.0.0.1 5910
error - problem connecting

After much trial and error, and many Google searches I discovered a post on the Ubuntu Forums from spider-byte describing exactly the same problem. His solution was to reinstall both XRDP and tightvncserver separately through synaptic. As a test I reinstalled tightvncserver with apt-get and voila, problem solved. I'm not sure if this is a common occurrence or just my config gone wrong, but I thought I'd share my solution and my thanks to spider-byte.

Mac user can't login to Windows domain

Had a quick question this afternoon from someone who had setup a Mac in a Windows domain environment. After setting up and joining the domain they had no problem logging onto the Mac with their Windows username and password. However, seemingly at random they were suddenly unable to login anymore.

It turned out to be quite a simple solution to the problem; the clock on the Mac was out of sync with the Windows domain controller. The Mac was running six minutes faster than it's Windows colleagues. Once the time was corrected the user was able to login to the Mac again with their Windows login.

Outlook 2010 cannot verify licence

I was reimaging a faulty computer today with a working Ghost image I had made some time back when I encountered an error opening Word. Every time I tried to open any of the Microsoft Office 2010 applications I got this error message:

"Microsoft Office cannot verify the license for this product. You should repair the Office program by using Control Panel."

After a bit of searching I discovered the answer was quite a simple one. The problem was that I had created the image some time back and the activation grace period had expired. In order to get Office to activate properly I needed to rearm the activation period.

To do this you need to open a command prompt with elevated administrator rights and type in the following command:

C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe

This resets the 30 day grace period and you are once again able to open and activate Microsoft Office.

ASUS P5 series motherboard won't shutdown with Windows 7

I had to share this little gem of a trick with everyone. I've just built a new quad core system for my wife to play The Sims on. Works perfectly except for one tiny little hitch - When you shutdown the computer Windows shuts down fully but the PC doesn't turn off; the fans carry on spinning and the lights stay on.

Many thanks have to be given to user kirk620 on the Microsoft Answers site for finding the answer to this problem. Simply go into Device Manager and find the entry for your IEEE-1394 device and under Power Management tick the box to allow Windows to turn off the device. Hey presto! The computer shuts down properly again.