Tuesday, 11 July 2017

Windows Explorer's GUI is really bad at long file names and folder structures - Don't trust it!

I am actually in a bit of shock at this one - I've hit the long file name problem in Windows a few times in the past, but it has never been that much of an issue.

A client came to me with a project to move a huge Dropbox repository (Millions of files, about 150,000 folders) to a new server. During this project and moving a few folders, I got the standard Windows long file name problem:

I've only ever come across this when I really thought I was at the limitations - however, I took a step back and tried to understand this.

My client used Dropbox - the location was originally "c:\users\username\dropbox\xxx\yyy\...[lots]...\zzz\file.doc" and the new location is "c:\temp\xxx\yyy\...[lots]...\zzz\file.doc"

Thanks then to a few people in Server Fault chat, it seems that the Windows GUI just lies and doesn't handle this at all well.

In fact, if I look at a folder that has ~750 folders and ~450 files, I see the following:

Moving the files with xcopy or robocopy works fine, or even using Terracopy.

In addition, some tools such as winmerge also fail at comparing looking at the large folder structure where as Beyond Compare was able to do it fine.

Luckily I decided to take extra care and manually verify these files - granted I have never dealt with so many large files on a single job before, but, I have always trusted the Windows property box and this has been a scary lesson for me.

Friday, 7 July 2017

Exchange Management Console Initialization failed upon opening

So, been messing around with SSL certificates trying to renew all your Exchange certificates and you have this as a side effect? Or, you just open Exchange Management Console and get Initialization failed message?

For the sake of people Googling:

"The following error occurred while attempting to connect to the specified exchange server

The attempt to connect to using "kerberos" authentication failed: Connecting to remote server failed with the following error message : The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic."


Simply open IIS and make sure your default site has an additional host header setup that matches in the error above.

I have no idea why this is caused - the default site on the machine is set to listen on all interfaces/ips and is the default site, and server name resolves to the machine - however, specifically putting the FQDN of the server in a host header fixed the issue instantly.

If you are not sure how to do this - you open IIS, go to the default site, click bindings then add and type the server there:

Hope this helps you.