Search Form

Storage Platform Migration: Mac to Windows

Storage Platform Migration Mac to Windows: The Joy. The Horror. My Nightmare.

Like a lot of Systems Administrators these days I work in a mixed platform environment of Macs and Windows. In Today’s BYOD culture this subject can make your blood boil. No matter where you stand on the war you can appreciate my struggle.


I support a foreign office of a creative nature. Naturally they are operating almost exclusively on Apple MAC machines. Their (very complex) file and folder structure resided on an Apple xServe:


While this platform has been functioning beautifully, it is tragically flawed. It cannot be expanded and apple has stopped producing it. Rather than band together several Mac Mini’s to achieve the over 3TB of storage this office needed, we chose to migrate them to windows based storage. I already support an office of MAC users on windows storage. It works. They are even (GASP) joined to the domain.


After the hardware was selected, purchased and installed, I began to discuss the migration plan with the users. I assured them this would be a very neat and tidy process, as I have executed dozens of large

scale migrations without issue.


I executed the migration in stages, after hours using Rich Copy from the windows system. This is where I ran into a problem. Microsoft windows has several file system constraints.

1. File and folder name length cannot exceed 260 characters

2. Special Characters are frowned upon, and some are illegal <>:”/\|?*

Consequently Rich copy was ignoring the folders that were RIDDLED with the characters and absurdly long file/folder names. Clearly another method had to be devised.


Mac being UNIX based has the CP command. SO I set about constructing the file transfer initiated from the Xserve. This is where I ran into a problem. CP in Mac OSX 10.5.3 is single threaded, also it doesn’t support any logic switches so I cannot exclude files that already exist on the destination. So every night I had to stop the job when the office opened so they could work, and had no way to resume from previous progress.


It is at this point I should have made the office work out of two locations and migrated the data in segments, however I was determined to make this a seamless process just as it has been for my previous migrations. Clearly another method had to be devised


Installed on this production server is a program used for backups called Carbon Copy Cloner. It has the logic to allow for progressive copy jobs. Excellent! SO I execute the copy job over the next several nights and spot check files and file counts. The following week I shut off the xServe and map everyone to the new 10TB Windows Storage.


Immediately some problems are identified. The users cannot rename files and folders. The MAC is reporting that the users do not have permissions. After some inspection I realize that the files and folders are opened and that is why they cannot be renamed.


Did you know that UNIX file systems allow the renaming of folders while the contents are opened? I couldn’t wrap my head around this so I tested. And it is true. Also in MAC OSX 10.7 finder there is an issue with SMB shares and releasing the hold on the file when the user is done with it. So we began upgrading to the latest version of OSX.

The following week, the users reported that some InDesign files were not opening correctly. This is where I ran into a problem.


Macs Utilizing HFS File systems have something called Resource forking. As I understand it, this is a method of de-duplication. The moral of the story is that Font files (that a design shop would depend on) frequently get forked in HFS. SO when I executed my copy job from mac 10.5.3 I transferred over 200 thousand font files in a format that cannot be understood by modern operating systems.


The recommended method to transfer fonts is to zip them first then extract the zip at the destination. Given the scope of work that was not an option. Also it had now been two weeks since they went live on the new file system so I can no longer copy en masse from the source as I might overwrite changes critical to their work.


Through testing I discovered that on the windows file system OSx 10.5.3 sees the font files intact, however OSx 10.8+ only sees corrupted UNIX files. But when looking at the xServe source data both operating systems see the font files intact.


I have also discovered that if I execute copy operations through the GUI (Painfully slow) of OSx 10.8 or higher I can successfully copy font file from xServe to windows 2012 Server.


Because of the time lapse between the source copy data and the current destination. I am now left with no clear alternative than to go folder by special character riddled folder and copy the font files utilizing a MAC workstation as an intermediary.


I take some solace in that I am not the first one to have this problem. And I feel that I have grown as a sysadmin.


My Joy: Bringing windows policy/management to a previously non windows non managed environment

My Horror: The realization that I cannot in fact know everything, and my attempt to be good to my users has gone sideways.

My Nightmare: Manually moving countless files between two servers using a workstation in a foreign country as my intermediary.

Join in, share your thoughts

You must be logged in to post a comment.