Windows Certificate Autoenrollment Triggers

It's been a while since my last post but today I'm back with a new post to clarify how certificate autoenrollment works in a Windows environment. To be more precise, what triggers this process and how does it work when you're using a client offline? As you know, the certificate autoenrollment feature is very handy to automatically request and renew both user and machine certificates for various reasons so sit back and read on.

Fuzzy Windows 8.1

I just upgraded to Windows 8.1 and noticed that all of my applications got fuzzy. Apparently, Windows has discovered that my display has a "very high resolution" (1920x1080) and tries to make everything better by scaling the fonts to a point where they get fuzzy. This was driving me mad as I thought my contact lenses were the cause. What resolved it for me was to disable scaling for each application.

How to configure EAP-TLS

Far too many times have I come across a wireless environment where it has been said that the authentication method in use is none other than EAP-TLS. This is good as EAP-TLS is not only the most secure method but also the easiest method from a user perspective, a rare combination in this day and age. Still, when looking over the configuration, it appears that most environments are using PEAP-MSCHAP v2 which isn't EAP-TLS at all. How can this be? Perhaps because PEAP-MSCHAP v2 is default. So, how does one configure EAP-TLS, then?

Error moving mailbox from Office 365

In a Hybrid Exchange environment (On-Premises and Office 365) one might stumble upon problems moving mailboxes from Office 365 to On-Premises, known as offboarding with the following error message.

Cannot find a recipient that has mailbox GUID <many numbers>

The reason for this error is that the mailbox has been created in Office 365 and lacks the proper attributes in the On-Premises environment. So, connect to Office 365 using PowerShell and run the following command.

Get-Mailbox john.doe@domain | fl ExchangeGuid

Next, verify that the remote mailbox On-Premises is lacking the proper attribute.

Get-RemoteMailbox john.doe@domain | fl ExchangeGuid

You'll notice that the On-Premises attribute are nothing but zeroes. Copy and paste the attribute from Office 365 on to you On-Premisies environment using the following command.

Get-RemoteMailbox john.doe@domain | Set-RemoteMailbox -ExchangeGuid <copied from Office 365>

That's is. Moving the mailbox from Office 365 to you On-Premiese environment should now work just fine. Or will it? If your On-Premises environment is published by Forefront Threat Management Gateway (TMG) 2010 you might also stumble upon the following error in your move request logs.

Relinquishing job because the mailbox is locked

Or the following status of the request.

StalledDueToMailboxLock 

This might by caused by server affinity of the published web farm or it could be as simple as flooding. If you're certain that affinity is working properly you'll have to do some work on your TMG server to fix the flooding issue. Check out the below link for detailed instructions of what to do.

http://support.microsoft.com/kb/2654376/en-us

Installation of Remote Desktop Web Access failed

If, for reasons unknown to me you stumble upon problems installing Remote Desktop Web Access on Windows Server 2012 in the shape of Error 0x800f0922, the following solution might just be your knight in shining armor. Firstly, locate any certificate bound to a site that doesn't show up in IIS with the following command...

netsh http show sslcert

If anything shows up, delete it with the following command for IPv4...

netsh http delete sslcert ipport=0.0.0.0:443

And for IPv6, the following...

netsh http delete sslcert ipport=[::]:443

That's it for now. Your Remote Desktop Web Access role should now install just fine.

Changes in Exchange 2013

There are many changes in Exchange 2013. Some of them are major changes but most are minor. However, some changes aren't mentioned anywhere. A couple of days ago, I noticed a few changes that really doesn't make any sense at all. I was attempting to transition an Exchange 2003 environment to 2013. Granted, this transition isn't supported and indeed not possible in a normal sense. Still, when transitioning from one Active Directory to another, this doesn't matter as we'll be using PST-files to copy mail content.

Using the trusted, old ExMerge tool, I began extracting all mailboxes below 2GB. After copying the files to the Exchange 2013 server, I then ran the command to import the PST-files to the appropriate mailboxes. Lucky for me, I decided to start with just one mailbox and see how it went. The new mailbox was of course riddled with gibberish causing much distress to the user in question. After some research, it appears that Exchange 2013 as opposed to its predecessors cannot handle PST-files in Ansi format. A rather strange feature to remove in my opinion.

Well, it doesn't end there. Once I was able to import the PST-files after converting them to Unicode, it would appear that the localized names of the folders have been changed. For instance, instead of just using the old name "Sent", this has now been changed to "Sent objects". What was wrong with the old folder names that have been used since... Well, since forever.

Still, it was worth it in the end as Exchange 2013 is just so much better than 2003.

2013 went RTM

A couple of days ago, both Exchange and Lync 2013 went RTM. What kind of impact this will have on the industry is yet to be unfolded. What we do know is that Microsoft is pushing towards the cloud with a closer integration and a seemingly seamless experience (pun intended). In my book, the biggest news will have to be the offline feature of Outlook Web App in Exchange 2013 which just turns the table upside-down.

Oh, there's Sharepoint and Office too but I'll leave that for others to mention...