Why I won't use MelbourneIT for domains any more

Recently I have had three new clients come to our company for IT support. Each one uses MelbourneIT's domain name services - MelbourneIT hosts the domain name, the registry of that name and the web sites. In all three cases I've needed to make changes to DNS records and have been unable to get usernames and passwords for the managed services from MelbourneIT, despite having the authorised users available and requesting the changes themselves. Emails with reset account details have never arrived and after an estimated 3.5 hours on the phone I've given up. We'll set the DNS records up somewhere else and migrate the domain to a new registrar.

Poor customer service like this is not unusual in the IT world. Often a client will ask who to use for the domain names, where to host their DNS etc. I've always had very good experiences with Westnet and now with iiNET, reasonable experiences with Telstra on the Business Broadband and associated services and good experiences with Netregistry. While my company is a Telstra Fixed and Data dealer, I'm not personally involved in that part of the business and we don't resell any of the other companies services. I've used Netregistry personally for some years now, and I have my DNS hosted with Westnet still. Both organisations have been great to work with and I'm very pleased with the experiences I've had. I recommend them both to people I have as clients and friends. Contrast that with MelbourneIT's apparently poor customer service and I won't recommend them to anyone - not until I see a real improvement there.

I don't quite understand why so many companies - some with great products - skimp on customer service. Most of the time, the client is buying the sales chap or the customer service rep as much or more than the product in question. I always keep this in mind with my own clients - great customer service makes for sticky clients - they won't leave. Admitting mistakes can be seen as very detrimental, but I've always found that the admission, an apology and a plan for reparation have always been very positive. I've read too that in medical circles, some hospitals and doctors are apologising if things go wrong and people forgive them enough to drop law suits. That's a bit off topic, so I'll drag it back. The technical support staff I spoke to at MelbourneIT offered support but have failed to follow through and this is something that is now impacting on my relationship with the clients - they've started seeking a scapegoat for the things that aren't happening in a timely manner and unfortunately we IT people all get tarred with the same brush to a greater or lesser degree. It's been frustrating enough I'll take my business elsewhere and my clients too. Unfortunate for MelbourneIT but good for others.

Adventures with migrating Windows SBS2008 to Windows SBS2011 - Part 2

We take up the exciting adventures in migrating Windows SBS2008 to Windows SBS2011. The day is getting older and the laborious task of migrating Exchange data looms before us. We start by creating new Public Folder stores and configuring them. There is quite a bit of jumping backwards and forwards from the source (old server) to the destination (new server) during this process. Note there is a bit of command line work here – I highly recommend using tab complete where possible. If you haven’t used this before, type the first bit of a command or location and hit the TAB key – it will bring up the first match to those characters. Keep hitting Tab until you get what you want. Typically if it’s a multipart command, I’ll type a few letters, TAB, then a few more letters, another TAB etc until I minimise the number of letters I have to type to the bare minimum. It’s very *nix-y J

The mailboxes for the users – fortunately small – are in the process of migrating. Next will be data files and shares. We expect this to take the bulk of the time for the process. Note that the public folders suggested waiting 24 hours for them to complete the migration (No way!). This particular site has no data in the public folders so we can safely blow past this part.

The exchange migration was relatively straightforward and simple for us – not a lot of data and all over in about 30 minutes. On to the file migration and starting with the UserShares I was pleased to see that the command used was Robocopy. As you’d know from this blog I really like robocopy and its venerable cousin xcopy. Those applications have been great tools in my arsenal. We also set up the second partition – all the line-of-business data will go in here and we’ve got around 70GB of data to transfer for that. The robocopy transfer of the UserShares folder ran at about 500MB / minute so we’re looking at about 140 minutes for the big data transfer. We thought we’d get a bit of a jump on a few other bits of the migration – namely WSUS but the source server was running flat out keeping up with its new brother’s demands, so that was a no-go. Much of the migration of Fax, internal website and a few other features we were able to skip as this organisation doesn't use them. We’re at 9.25 hours so far and making good time (touch wood).

We RDP’d into the old server – turns out the console was misbehaving and started cleaning up WSUS. This process took 10 minutes by itself. Then it was time to set it up to migrate to the new server. The data copy was still proceeding and the log file was over 6MB in size already. We reviewed WSUS and decided to stop the migration – we’ll download it afresh and configure it only for the existing machines, cleaning up lots of other stuff in the meantime.

Creating a spreadsheet for all the share permissions is a handy thing to do. If you've got a lot of folders, with complex permissions I find this to be a good way to keep them all straight. It’s also a good opportunity to review Security Group membership and how these groups are applied to folders.  Robocopy with the switches the documentation suggests /COPY:SOU brings across all your ACL information so security is pretty easy to get going.

We’re up to the finish of the migration. We need to demote the old server, remove Exchange and a few other tasks. It’s a bit scary – this is the end stage. Luckily we still have the backup in case things go pear shaped. Here we go.

Removing Exchange 2007 from the old server proved challenging. There was a few difficult moments, an early “Who’s your daddy!” cry, then some silent weeping and finally success. I won’t bore you with details – sufficient to say it’s a bit of a process but our Google-Fu was up to it. The actual process of removing Exchange was surprisingly slow too – the files took a long time to delete. Not sure why – they aren't that big, and yet, 15 minutes after it started deleting them, it’s still going.  Once this process finished, we removed A/D Certificate services and then demoted the server. Rebooted and remove from network. Apparently we should now be done with the old server.

Uh Oh! It turns out that the users’ roaming profiles weren't properly copied across! Oh Noes! Powered up the dirty old server and started copying data across to a USB memory stick. Although it’s only 5GB the files are all little and so the copy time is suggesting 1 hour 20 minutes (!) I think this is uncool and my colleague agrees. Fortunately this does give us time to try and fix another issue that’s cropped up – the desktop PCs haven’t updated where they are supposed to get the redirected folders (Desktop and Start Menu) from. They’re still looking at the old server. So, with more swearing – as it is now 6:30PM and we've been at this since 8am this morning – we tackled the next issue. The desktop PCs registry’s suggest they are looking in the right place but the folder redirection still fails (it’s looking at the wrong place still so the issue of having no data there isn't yet a big one). Running gpupdate /force hasn't seemed to fix it yet. We’ll update the files, then try again – especially because the RedirectedFolders is empty – we had copied that data across so not sure what happened there.

This is a longer than anticipated process – the 5 or so GB of data is all very small files and so takes ages to copy across – more than an hour to copy it off, and only about 20 minutes to copy back in.

We found that the desktops were continuously looking in the wrong place – they were using the old server’s name in the UNC. Rather than update a million shortcuts on desktops and keep fighting the desktops I added a CNAME in the DNS to point the old server name back to the new server. Everything started working! We did find a multitude of strange, legacy shares that required recreation, so try to get all this down on paper before you get started. By this time we’d been at it for 15 hours each and we were starting to get a bit pissy. Thankfully Outlook and most other apps continued to work – we didn't need to create new profiles or anything.

We found that Exchange also had no outgoing connector to send email out. Internal email worked fine and the server was receiving mail but we couldn't spam, uh, I mean email, anyone. There was no Hub Transport Send Connector created. We got this going and suddenly the queued mail we had sudden flowed through. It was quite spectacular really – we’d sent a *lot* of test emails J

It was at this stage we made the executive decision that all the major boxes had been ticked and the network was operational. We had allotted 16 hours for each of us and we came in at 15.5 hours. Not too bad at all. We’ll no doubt have some problems on Monday but for now we’ll knock off and collapse at home. I hope some of this information is informative or at least entertaining. Here’s hoping your migration goes as well or better.

Adventures with migrating Windows SBS2008 to Windows SBS2011 - Part 1

Approaching a major migration can be a very stressful event, especially with a Small Business Server involved in the mix. Migrating one from exiting to new is even more fraught with danger. Over the course of this weekend, we are migrating a Windows SBS2008 server to a brand new Windows SBS2011 box. There is some great documentation from Microsoft about this process and I’d like to share some of the experiences we had.

Firstly, it’s critical to assemble and test the new server before anything else. Give yourself enough time to do this. Even a pre-built, delivered by HP/Lenovo/IBM server still needs testing on your part – disk, RAM and CPU at the least. Build your RAID arrays too , have them prepped and ready to go for installation. Also, identify what drivers you will need – particularly RAID controller drivers and network adaptor drivers. If you've got the NIC drivers, then you can download any others you might need.

Getting the right documentation is helpful – the Microsoft Migration documents are very thorough (and long – 60+ pages) but are pretty well step-by-step. A very large USB drive is also handy and a laptop with internet connectivity is always a must.

We ran through the initial stages, getting the 2008 server patched up to the levels required for the migration. Then a backup of the C drive – we’ll migrate data via the network later. This reduced our backup from 250GB+ to under 90GB, which took a little over 30 minutes to complete. Then, the SBS2011 disk went into the old server and the migration prep tool was run. We created an Answer File (needed for the new server) and called it a night – it was a Friday after all and around 8pm.

Next morning – installation of the new server started. Drivers for the RAID controller and NIC were needed pretty quickly. When you run the installation it gets run in Attended Migration Mode – the migration process gives you 3 weeks to complete the migration, with the possibility of having two domain controllers on the network at once. After this time, the initial server stops working and that’s that. We experienced a BSOD trying to get the network card drivers to work – ouch! Here’s hoping it recovers back to the same point in the installation…. And it more or less did, except the server doesn't have the option to install a network card driver like it did. Two options only – Test Network Connection and “How to troubleshoot network issues” which opens the Help documentation. There’s nowhere to install a driver or configured the NIC. Hitting cancel shut the server down. Uh oh. We’ll crank that mofo up again and see what happens. Remember too, the network adaptor's IP has been pre-configured via the Answer File – this actually worked.

The server rebooted and now it wants to activate because the activation period has expired. How the hell did we get to there? OK, we've chosen to enter the activation code (cause we haven’t put any codes in yet). We got to that and now we’re back at the same screen about the server being unable to proceed because it doesn't have a network connection. A three finger salute (CTRL/ALT/DEL) allowed us to access Task Manager and get to the Device Manager from there. Remember how I mentioned it would be great to have the right drivers handy? We thought we had the right ones, but alas, they were not. After hunting around and testing several different drivers, still no luck. I’m sure there’s more on the HP website and there is… let’s try some others!

While that process was going on, I looked into some details about Windows SBS 2011. From the Microsoft OEM site:

“Designed and priced especially for small businesses with up to 75 users, Windows SBS 2011 Standard is a complete solution designed for customers who want enterprise-class technologies in an affordable, all-in-one suite.

Built on Windows Server 2008 R2, Windows SBS 2011 Standard includes Microsoft Exchange Server 2010 SP1, Microsoft SharePoint Foundation 2010, and Windows Software Update Services.

Windows SBS 2011 Standard is a great opportunity for small businesses with prior versions of Windows SBS to upgrade their servers and to simultaneously take advantage of the advancements in security, reliability, and connectivity technology.”

Interesting indeed. SBS2011 is the last SBS. Windows 2012 Essentials doesn’t include Exchange and therefore becomes very pricy for small operations. Bring on Google Apps for that. At any rate, we've now downloaded the HP ProLiant Support Pack and installing it – 33 minutes to complete! Once this finished all the hardware driver issues were resolved and the server continued on its merry installation way. Sadly the Server Activation issue cropped up again and suggested we were victims of software counterfeiting – oh noes! Attempts to resolve this ended up in another reboot – which is usually OK but it does take a while. After restart we found the DNS wasn’t working – we adjusted it to use the ISP DNS and the server rebooted again, without much in the way of a by-your-leave. With the server live again the installation/migration continued.

The latest reboot resulted in the migration continuing and the Windows Activation windows popping up – this type the Activate Online was successful and the migration tool continued to expand and install files. 30 minutes until it finishes!

So it turns out 30 minutes was conservative. An hour on and the process was still running. We had time for coffees, pies and sandwiches. Hopefully it will finish soon…. During the interminable time while it does the migration, we noted that DHCP had stopped working  on the network. This was being delivered via the SBS2008 server and shouldn't have been affected. We restarted the service and DHCP was restored. We’re not sure why that failed.

OK so it was more like 90 minutes than 30 minutes. The server rebooted – hopefully because it’s supposed to and Windows is starting again. Sadly the process is still continuing after the reboot and the internets tells us it could do it 2 or 3 times!

After two hours the expand and install files process completed. It is now time to run the Migration Wizard, starting with File locations. This includes Exchange files and data files. We went through and used the default locations, then detected the network. It picked all this stuff up correctly and the exciting journey continued </sarcasm>.  We’ll take up the migration in the next blog post – where we begin with migrating Exchange data.

Adventures with the Cisco SRP527 ADSL2+ Router

This is a review of the Cisco SRP527 ADSL2+ router as much as it is an overview of my experience

with it. For a long time I was a huge fan of the Netgear DG834 series routers - for around $100 you got a router capable of wireless, 5 VPN tunnels, reasonable (but not fantastic) firewall and very reliable. It's only been since Netgear cancelled this excellent series, pushing users to the higher end models for VPN and using other, non-VPN capable routers for home users, that I started casting further afield for a new, reasonably priced VPN capable ADSL2+ router. WiFi wasn't that important - TPlink do a reasonable wireless access point for around $60 that we've deployed very successfully and I don't mind the separation of devices. One of my colleagues heard me bitching about the Netgear changes and suggested I check out the Cisco SRP range of routers. Usually the only Cisco routers I've played with are 800 series ones, or 1900 series - routers that require care and patience to set up, plus command line skills that I don't really have - I'm a *nix dude after all.

He was using the SRP547, the higher model than the one I use now, at home and loved it - he was able to control his kids access to YouTube and Facebook, killing their WiFi so they'd sleep and allowing him full access to his bandwidth :-) More importantly, they are reasonably priced and capable of both WiFi and VPN support. We started to sell a few of these devices and recent events enabled me to pick one up for home. I need a VPN to the office for remote backups, maintenance and monitoring so it was an excellent choice.

The Cisco SRP527 is an unassuming looking beast. It's in the same chassis as the 547 (and the RVS4000 for that matter) and offers a wealth of configurability. First things first - it has a web based front end that is clear and easy to navigate around. There are a lot of options, but they are fairly intelligently divided up and you can follow your nose looking for things. I set up my ADSL credentials, configured my firewall - note that you have to set up the Port Forwards, then the Advanced Firewall to get things moving in the right directions. I made the error of assuming that since I'd set up the Advanced Firewall options I didn't need to do the Port Forwarding - you do. But you don't have to set up the Advanced Firewall if you're allowing any access to the port forwards.

The 527 has 4 10/100 ports, one of which can be used as a second WAN port. It has 802.11N wireless capabilities and 2 phone ports

Rightly placed under the Cisco Small Business SRP500 Series Services Ready Platforms on the Cisco support pages, these are terrific devices. Not only did I have it up and running, with the VPN connected successfully to the SRP547 at the office, but I picked up almost 1Mb in speed on my ADSL line. Not bad at all for 15 minutes work. Even setting up the SRP547 at the office, with *many* more port forwards and some quite complex routing only took about 45 minutes.

The thing that probably impresses me most about this device is the reporting. The status page gives you a breakdown of so many different things its amazing. I can see how much data the port forwards are doing - individually, I can see WiFi stats, ADSL stats, VPN traffic stats and so much more. For someone like me it's awesome - I can watch this while I'm testing various different pieces of hardware and things that I'm doing - useful if I'm trying to work out what's sucking the life from my internet connection.

Things to note - when upgrading the firmware make sure you pick the right one. I inadvertently used the SRP520 firmware instead of the SRP520U firmware. Luckily a restore from backup fixed everything. With a reasonable price tag and lots of stuff it can do - it's well worth checking out the Cisco SRP527. With a bit of extra coin go for the SRP547 and get gigabit network ports!