After a hiatus of a couple of years I have recently come back to working with Windows servers – besides OS X and various Linux distributions, which have been my usual working tools lately. I realised that my old tools to access Windows servers would no longer do the trick. The Microsoft Remote Desktop Connection Client for Mac was never really very good but I had become used to Cord and it, too, would no longer work.
Apparently the problem is due to a difference in protocols between the client and the server and the two couldn’t negotiate properly on what protocol to use. I first tried to modify the server to default to the old RDP protocol and not try TLS. I even kept a virtual Windows client at hand to run whenever I felt a need to connect to a remote Windows server.
It turns out the absolutely best solution in these cases is to use the Microsoft Remote Desktop app, available on the Mac App Store for free. It is truly a great application for this purpose and allows the user to keep a list of servers and connect to them quickly and easily. For the ultimate in user experience, run the Windows terminal full screen and use the three finger swipe to quickly switch between the remote server and the local OS X system. Sweet!
Over the years I have used many small applications to extract metadata from images but none of them were as versatile as Image-ExifTool by Phil Harvey. It support just about any image or video file format your can imaging. And a nice thing is that it is implemented in Perl so that one can easily use it to build a script. And it works cross-platform which is important for me who move between three operating systems on a daily basis.
This is all it takes to extract all metadata from a file:
I have had my Canon EOS 20D since early 2005. The first few weeks I set the camera to save images in JPEG only. After a while I switched over to saving images in both JPEG and RAW and have been doing so up until this year. Up until last year I had been using Windows XP and Windows Vista and having JPEGs around made it easier to look at the photos. However, about a year ago I switched over to Mac and am now using Aperture 2 for my photo cataloging needs. There, the presence of both JPEGs and raw images is nothing but annoying.
To avoid the problem with both formats in Aperture I want to import the raw images where available and JPEGs otherwise. But I can’t just remove the JPEG files on a folder level because some images are only available as JPEGs. And with literally tens of thousands of images I just didn’t want to do it manually.
The attached Perl script solves the issue. It takes a source and a target folder as arguments. It then goes through the source directory hierarchy and copies all the image files to the target – but skipping files that are available both as RAW and JPEG. In that case it will pick the RAW file. It uses embedded EXIF tags (the time the photo was taken plus the serial number of the image) to judge if two images are the same. Further, it retains the folder structure but removes certain folders to flatten the target folder structure – I had originally put the RAW files one folder down so that they wouldn’t interfere with the JPEGs when viewing them in Vista’s image viewer.
Please note that I can only vouch that this works on CR2 files and JPEG files from a Canon EOS 20D as that is the only thing I have tested it with. It should be simple to adapt it for other cameras. Also note that the script does not test whether the target folder is empty. You are advised to test the program on some files that you don’t mind losing before you apply it to your entire image library.
I called the script photo_prune, despite the fact that it doesn’t actually prune the source data. To avoid data loss it instead copies the data to a new location.
I have had my Dlink NAS DNS-323 since early 2007. It has mostly served me well. Over the months I have put more and more files on it so that it now holds about 350GB of data. Out of fear of losing precious data I have not updated the firmware so I am still on 1.03 from May 2007.
I mounted a shared folder on the DNS-323 from a Ubuntu client and noticed that the Swedish characters were all messed up. First I thought the error was related to how I mounted the drive from Linux, but then I found out that the issue is with the DNS-323 itself and the fact that it uses a non-Unicode character set for the filenames. This should be solvable with the iocharset and the codepage parameters to the mount command in Linux but I couldn’t get it to work.
Later firmwares are said to fix the problem – but only if the drives are totally wiped. I got myself a USB drive sufficiently large to hold everything and copied all the data over using rsync so now I am just about ready to upgrade the firmware and reformat the drives and use some of the plugins on http://wiki.dns323.info. But more on that some other time.
Before I wipe the disks I wanted to make sure that I could rename all the files using Unicode but with some 50,000 files I didn’t want to do it manually. The Linux command iconv can convert between encodings but it works on a file level and I wanted something that only touches the filenames, not the contents of the files.
I found the Perl command convmv which is available through the standard Ubuntu repositories. Just type “apt-get install convmv”. It does the same as iconv but on filename level. Precisely what I needed. I then typed:
#/mnt/wd640gb# convmv -f cp850 -t utf8 -r .
This command shows how files would be renamed, switching from codepage CP850 (the default or DNS-323) to UTF8. Once you are happy with the suggestions, just issue the command again but with the extra switch –notest to actually rename the files.
My only issue now is that convmv only works on filenames, not directories. But at least I have reduced by problem by a factor 30 or something. The directories I can do manually.
Earlier this year we (or rather, myself) migrated to Exchange 2007 at work. We are not a big company but even so (or perhaps because of it) we have a rather heterogeneous set of client devices. People connect using Outlook 2003, Outlook 2007, Entourage 2008, Evolution, Apple Mail, Thunderbird and all kinds of mobile phones for both standard IMAP/SMTP (with encryption of course) or Microsoft licensed ActiveSync.
Before the migration we had a frontend Exchange server and three backend servers but after the switch we have just one Exchange 2007 server. Immediately after the switch, people started complaining that non-Microsoft mobile phones could not sync against the server using ActiveSync.
Since we are rather literate when it comes to computers we had set up an internal public-key infrastructure with a root certificate authority under SSL. The Windows domain included a certificate authority running as a subordinate authority which, in turn, had signed the SSL certificate for the Exchange 2007 server. All was done according to step-by-step guides from Microsoft. When accessing the web mail or using ActiveSync from Microsoft based mobile phones it worked. But it just wouldn’t work from Symbian phones – despite the fact that they had licensed the ActiveSync technology from Microsoft.
We tried all kind of settings before we eventually found the problem. It turns out that Exchange 2007 uses a relatively new (but still quite old) feature in SSL certificates called “Subject Alternative Name”. It is a feature that allows the certificate to be used for multiple host names and not just a single Common Name. The combination of Exchange 2007 and the subordinate Windows certification authority caused this extension to be set as “Critical” in the certificate which makes the certification check fail for any client that does not understand the Subject Alternative Name – which is exactly the case for Symbian phones.
The solution was simply to create a certificate by using OpenSSL alone and flag the extension as non-critical. The common name used in the certificate is still the only name used by ActiveSync clients so they have no problem with this change. The new host names in the certificate are to my understanding only used by Outlook 2007.
On Mac OS X
Type “sudo nslookupd -flushcache”
DNS records are not cached locally unless you have installed a local DNS server. Intead DNS records are cached in the upstream DNS servers.
Type “ipconfig /flushdns”
I have been using Sharepoint at work for a number of years now. In theory, it is a good product that takes away some of the anarchy that usually is the result of a just using a file share to exchange documents. In practice the benefits are less stellar, especially in a mixed environment.
Since starting to use a Mac in what is otherwise a Windows shop, it has become painfully obvious how much one ties oneself into the Microsoft world by using Sharepoint. People might be concerned about being locked in to Office but that is nothing to Sharepoint. Unless you run the combination of Windows, Office and Internet Explorer you are in for a rocky ride indeed.
So, trying to get out of Sharepoint, what do you do? You may still have a lot of documents saved there that you don’t want to lose.
I tried using wget but it wouldn’t download everything. I then tried httrack but it wouldn’t follow links into subfolders in document libraries (I did keep a copy downloaded by httrack though since it managed to keep most of the contents). I also tried to map UNC paths to the document libraries to be able to copy the documents that way. Didn’t work. I tried various freewares that were supposedly able to archive documents from Sharepoint. Not so.
Then I tried Sharepoint Documents Exporter by Brennan Stehling and that did the trick. Finally, I got a complete set of files directly from the MSSQL server, including files saved on the users’ private pages.
Now the big question remains: Should I head back to the file share or is there some open source Sharepoint wannabee solution with support for multiple client platforms, full browser compatibility and support for both Office and OpenOffice? Drop a comment if you have a suggestion.
Exchange 2007 brings some new changes to the table but for many, like me, who have to migrate from a previous version it can be troublesome. All features of previous versions seem to be there but for some reason many of them are not available from the GUI but instead have to be configured via the new shell console. Personally I would rather have a strict file-based configuration than the strange mix here but switching from Microsoft was not on the table. One setting that was missing from the GUI was the ability to set a DNS blacklist to use to detect incoming spam mail. I wanted to use the Spamhaus Zen blacklist and had to enter the following command:
Add-IPBlockListProvider -Name zen.spamhaus.org -LookupDomain zen.spamhaus.org -AnyMatch $True -Enabled $True -RejectionResponse “Your IP is blacklisted! http://www.spamhaus.org“
Having to manage a bunch of Windows boxes made me download and install Microsoft’s Remote Desktop Client almost as soon as I switched back to using Mac last summer. First I used the current version but as soon as the beta of the Remote Desktop Client v2.0 came out I started using that. A couple of weeks ago I started getting this notification:
However, there is no file to download. Apparently, the application timed out on March 31st but we have yet to learn from Microsoft when the proper version is due.
CoRD to the rescue. CoRD is a SourceForge hosted project to create a free remote desktop client for Mac – and it rocks.
Unless Microsoft comes up with some extremely useful features in their client, I won’t be switching back to RDC.
The combination of Ubuntu 7.10 (or any other 2.6 kernel based Linux distribution) and Virtual Server 2005 R2 leads to extreme clock drift, causing the clock in the guest operating system to drift several minutes per hour. This amount of drift is beyond what NTP can normaly cope with and while some people have advocated running ntpdate as a cron job every hour, such an remedy would only reduce the issue since it would drift many minutes before it would be reset again.
Microsoft has issued a knowledgebase article that describes a solution to the problem.
In short, add “clock=pit” to the kernel options in /etc/grub/menu.lst.