SEMblog

In my house April 1st is greeted with some trepidation.

I don't mean the April fools jokes, trying to spot when friends and families are trying to catch you out, but something else.

For me, April 1st is when I hear if Microsoft have honoured me with MVP status for another year.

MVPs are awarded annually, and this happens every quarter. I am on the 2nd quarter, so get the email on April 1st. No doubt there are many newcomers to the programme who think it is a joke, particularly if they haven't had contact from Microsoft beforehand to give them an indication that they are being considered.

My MVP, for the Microsoft Exchange product, was first awarded in 2005 and I have been fortunate enough to be re-awarded every year since. It is nice to be recognised for the contribution I make to the Exchange community.

This year April is looking like a busy month, with Cumulative Update 1 for Exchange 2013 being released and the migrations to the new version beginning. 

Ten years ago I sat in my small flat in Hampshire, logged on to a web site and after handing over my credit card details a new company was born - Amset IT Solutions Ltd.

The name Amset I had been using on and off since 1997. At my first real IT job all of our computers were named after Egyptian gods and mine was called Amset. I continued to use that name for computers later in my career and when I was searching for a name it was the natural choice. I had amset.co.uk since 2000 but being naive, I had failed to pick up amset.com, which was registered a few months later. That wasn't a mistake I made again.

The idea at the time was to be an IT support company. I had been made redundant again and the job hunting wasn't going very well, so I decided to go it alone. That had always been my life goal, but it was earlier than I expected.

I took a mortgage holiday and had savings from an aborted house purchase earlier that year and took the plunge.

Alas my first foray wasn't very successful. I engaged a marketing company to assist me, but it quickly became apparent that I was going to struggle on two main points.

I didn't have a unique selling point, so it was impossible to make myself look different to all of the other IT companies out there.
The other problem was that it was just me and when companies asked about what would happen if I was unavailable, I was unable to answer (what I have called the run over by a bus question).

I did acquire one client in those first few months, and they are still with me today.

Therefore by September 2003 I was running out of money. The mortgage holiday was about to end and I had almost no business to show for it. I took a contract to keep my head above water and then found myself a full time job. I retained the company, but in that first year I turned over less than £5,000 - the company made no profit, owing me more than that.

The next financial year was even worse, with the company turning over less than £1000.

In 2004 though, I was introduced to Exchange 2003. My employer wanted to do a migration and I had to learn fast. I spent time on forums and realised I was able to answer more questions than I asked. That set me on the path to Exchange MVP status.

In late 2005 I got my first major Exchange job of my own. I took ten days off work and went and worked for them. I earned more on that first job for eight days than I did in four months at my full time job. It will not surprise you that I came back and immediately handed in my notice. I was on a three month notice period, so in February 2006 Amset IT Solutions Ltd became my employer again. 

In early 2008 I had an inspired idea in the shower one morning, and created certificatesforexchange.com, which has been a huge success.

In 2009 I decided to change the company name to Sembee Ltd, as that was the name I was known as on the Internet, and it seemed a good idea to trade on that name rather than the previous name. I had already been using it for my personal Exchange blog, but it was becoming apparent that it was all merging together.

So here I am in 2013, with a successful limited company that has been based on all of my own work. The Exchange work is done exclusively by myself, I don't contract the work out. It was a very difficult road, but the work has paid off.

If you are thinking of starting your own business in IT, then some words of advice.

If you are on your own - specialise. Being too generic and you will just get drowned out by all the other generic companies. However do not be too focused. While I am an Exchange specialist, because of my background in general network administration I can do some Active Directory work, I often setup domains and resolve other issues unrelated to Exchange. My oldest client in Basingstoke I maintain their entire network, one of the handful that I do that for.

The next piece of advice is you need cash. I don't mean to get the company off the ground, but to live on. I took a mortgage holiday, but I was still burning through a lot of money every month. Work out what you need to live on and have at least six months buried away. I now retain six months of funds at all times - I keep mine in Premium Bonds. I can get it if I need it, but I don't have immediate access to it.

The final piece of advice is to take a break as often as you can. For some months while starting the business and the second coming in 2006 I didn't talk to anyone other than clients. Didn't step outside of my flat, was completely isolated. Not good for me.

While taking a holiday isn't always a good idea at the start (being away from a new business for a week or more might be fatal) there is nothing to stop you from getting away for a few hours.
I started to visit the New Forest, which is about an hour away, going right down to the coast. There I would visit Hurst Castle, which is on the end of a long spit in to the Solent. I would just walk out to the castle, walk round and then walk back. My Blackberry works all of the way because the Isle of Wight isn't far away, but it got me out and because of the wind blew the cobwebs away. Very invigorating and just cost me the petrol money.

I hope you have found this article interesting. I will be returning to blogging on Exchange over the next couple of weeks. Here is to the next 10 years. 

SSL certificates are a constant source of pain for Exchange administrators. With Exchange 2007 and 2010 so heavily dependant on web services, getting SSL setup correctly is important for correct operation. 

A lot of SSL certificate deployment is now being done for mobile device support, and then you open a new issue - SSL certificate compatibility. 

Recently I found a large list of SSL certificate and client compatibility. 

It is from a Danish SSL reseller called FairSSL:

http://www.ssltest.net/compare/sar.php 

Most useful for mobile platform compatibility, the combinations it lists are significant. 

On the same site they also have a tool to verify that your SSL certificate is installed correctly. Most of the SSL vendors also provide this, but if you don't have the login details (perhaps because the certificate was just supplied to you) then it is a useful service to have:

http://www.ssltest.net/ 

With more SSL providers now using intermediate certificates to issue the certificates, rather than the root, getting the certificates installed correctly can mean the difference between SSL working and not. 

[ad]

IPv6 has and continues to cause a lot of confusion for network administrators. I suspect that a lot of it is down to misunderstanding about the new system and therefore people blame it for problems because it is new. 
In forums, I see a lot of people who simply post that the problem is "IPv6" and it should be disabled because it is "known to cause problems". I have been asked to clean up Exchange deployments where IPV6 has been disabled, simply because the installer believed it would cause issues if it wasn't. 

In many cases this is simply not true - IPv6 is not the cause of many problems and in the default configuration on Windows 2008/2008 R2 will not get in the way of day to day operations. 

However IPv6 is not going to go away and very soon most network administrators are going to need to do something with it, whether they like it or not. Therefore getting experience with it now, before being forced to do so can only benefit the network administrator. 

Back in the summer, just after the World IPv6 day, I decided to look at using IPv6 myself and have been running an IPv6 network at home ever since. The web sites that I operate are also IPv6 enabled and if you are already using IPv6 you may well be reading this blog posting having accessed the site using Ipv6. 

Initial Experiences with IPv6

Having now lived with IPv6 for a few months, I thought I would write up my experiences with using it. In brief, I have found it to be largely trouble-free. I was caught out by a few small issues at the beginning, but after being setup correctly, it has been largely set and forget. 

IPv6 Addresses and Getting Started

The first thing you have to do is get hold of an IPv6 subnet. Most ISPs are currently not issuing IPv6 addresses, so you have to source them from elsewhere. Having researched on the easiest way to do this, I settled on using a tunnel broker, specifically Hurricane Electric (HE). 
It was easy enough to sign up with them, and before long I had the single address required. HE are giving out the addresses free, and allow you to choose where to create tunnel to. I chose London, being in the UK. 

I built a Windows 7 machine in a virtual machine, and followed their instructions to enable it - which was simply a matter of entering some commands in to a Command Prompt to configure the tunnel, which Windows 7 supports natively. 
For the tunnel to create, HE need to be able to ping your EXTERNAL IPv4 address, so a firewall change might be required. 

Once entered, I tried to ping ipv6.google.com, only for it to fail. 

Therefore I hit the first problem, which is probably the most common issue with IPv6 - hardware support. 

I am fortunate that I have dual internet connections, regular ADSL and a cable internet. My ADSL had a Cisco router on it, and I quickly discovered that Cisco only support IPv6, even pass through, on specific OS types and I had the wrong one. I wasn't paying for the upgrade for a test (And was planning to drop the Cisco router a few months later when I got fibre internet), so I decided to use the second connection. 

Switching over to my cable internet connection, which used DDWRT, the tunnel passed through immediately and I was on the internet using IPv6. 

I have to say, it was a rather underwhelming experience - it just worked. 

Putting the Network on to IPv6

With the single machine on IPv6, I thought I would see if I could put my entire home network on as well. This meant the router needed to support it. I played around with DDWRT for a while, but found it wasn't easy to configure with IPv6 information. Therefore I changed my attention to my public web server. 

The web site that you are reading this posting on is actually a virtual server. The firewall that protects it is a VM, and generally I can do what I like with the system. A look around at other software firewalls it quickly became clear that the best one for IPv6 was monowall. It didn't take long to install a fresh VM with monowall and used a spare external IPv4 address. 

After requesting a second subnet from HE I entered them in to the firewall and I was online. Took minutes to configure monowall. I then set the firewall rules so I could ping out etc and all was good. I modified the firewall rules to allow inbound traffic and after a few minutes configuring the DNS records, I was able to browse my web server with IPv6 from my test system at home. 

Using IPv6 also gives the strange sensation of the same IP address internally as well as externally. No NAT involved. I haven't been in that situation since a job back in 1999, where the employer had enough public addresses that we could use them internally as well. 

IPv6 Addresses

One of the things that did start to cause me a headache was dealing with the IP addresses themselves. You have so many and they are so long. However I quickly learned about the "::" shortcut, which allows you to shorten the addresses. What this means is that instead of using:

2001:470:1f09:1ab5:0000:0000:0000:0090

I can use this instead:

2001:470:1f09:1ab5::90

From an understanding point of view, I found that using the same number at the end of the IP address for both IPv4 and IPv6 made managing the addresses much easier. For example this blog is on 85.234.131.90, so I used ::90 at the end of the IPv6 Address. 

With the addresses configured on the web server, it means I can just look at the last number to ensure that I am putting in the correct bindings to the web server. 

Boyed by the success of getting the public web site to work, I looked again at my home network. Switching the DDWRT router for a monowall virtual machine meant that I was able to configure the home network for IPv6 quickly, and also meant that I now had a static IPv6 address running over my dynamic IP address cable internet connection. 

With the addresses the length they are, you have a lot of addresses available to you. 

I subnetted my allocation down further, which has allowed my labs to have their own IPv6 subnet. This means my labs "could" be seen from the internet, if I set the rules to allow that to happen in the firewall. Once IPv6 is widely used, I can see that as a major advantage, particularly if you are testing email servers. 

DHCP or Not

One of the features of IPv6 is that removes the need to have traditional DHCP. Instead you enter information on your router and it is able to "announce" that information which IPv6 clients are able to find. 

Microsoft do provide an IPv6 DHCP server, which I had some success configuring, but as the information from the router was correct, it wasn't something I pursued. 

Most of the systems on my network I entered static IP address information for, but I did find they were getting an automatic address as well, which must be a feature of IPv6. However when reviewing WSUS for example, the static address I assigned is being entered in to WSUS as the server's IP address. 

The impression I am getting though is that the IP address of the system is going to be less important, at least internally. I have set static addresses in the public DNS and on the servers, and those work correctly, but internally the network is also using the automatic addresses. 

With the length of the IP address, remembering them for doing testing isn't going to be easy. Therefore I can see in the future that DNS will become more important, so that you can simply ping or nslookup the host name, to get its IPv6 address, then work from there. 

DNS

I mentioned DNS above. 

Backwards compatibility for DNS on IPv6 works really well - you have two entries for most things - an IPv4 A record and an IPv6 AAAA record. The AAAA record takes priority. 
This can of course give unexpected results, particularly when troubleshooting. Therefore what I have done is create three records for hosts where I am likely to want to do troubleshooting (mail servers mainly).

1. The regular host name - so host.example.com - both A and AAAA records. 
2. A IPv6 specific host name - so ipv6.host.example.com  - this is an AAAA record only. 
3. An IPv4 specific host name - so ipv4.host.example.com - no AAA record. 

A good example of this in action can be seen on a basic IP address display site I built. 

If you browse to the site normally then you will have the IPv6 address displayed if you are using IPv6 and the IPv4 if you are using IPv4. 

http://ip.sembee.info/ 

However further down the page are links to other versions of the page - one for displaying just the IPv4 address and then one that displays both IPv4 and IPv6. Moving through the pages you will notice that the host name in the browser bar changes, so that the correct DNS entry is used. 

Email

As an Exchange MVP, I was of course interested in how this would work for email. 
For email it is just a matter of adding the additional AAAA record for the host name. 
MX records point at host names, and then the client resolves the host name to an IP address. 
Therefore my MX record hosts have both IPv4 and IPv6 addresses. 
Although monitoring the email I have found that I have received just three emails (all marketing) from IPv6 hosts. 

Drawbacks with IPv6

The major issues with IPv6 is support of the address type. 
I quickly discovered that the antispam solution I am using cannot cope with IPv6 addresses, but as spammers aren't using it, it hasn't been a problem so far. 
I also discovered that my web stats application doesn't support IPv6, so I have no real ideal how many people are accessing my web sites with IPv6. Certain applications also have issues with IPv6, but in a lot of cases this is only if it is pure IPv6, not a mixed network. 
The length of the IP address I think will be something that many network admins will find difficult and will miss being able to type in the four sets of numbers from IPv4. I fully expect IPv4 to be used internally for some time to come, perhaps with IPv6 being used just for internet traffic.

Conclusion

As you can test Ipv6 with almost no disruption to the production network, it is something that network admins should take a look at, so that they simply get their heads around it. Then as it becomes more widely used, they  have already been through the learning curve. 

An interesting little issue with a client's configuration caused a problem recently.

The problem only affected users off site using Outlook Anywhere. While they could get their email correctly, the availability service didn't. This stopped Out of the Office from working correctly unless OWA was used, or the end user was in the office.  

This particularly configuration uses a Client Access Server in a data centre, which proxies over a site to site VPN in to the main office where another CAS, plus the mailboxes are actually located. Therefore the issue had to be around a configuration difference between the two servers. 

Running 

get-clientaccesserver servername |fl 

on the server in the data centre and comparing it to the server in the main office, showed that the value for AutodiscoverSiteScope was populated with the AD site for the main office. This was because the server in the data centre had been built in that location initially and then moved. 

Removing that entry so it was blank resolved the issue:

Set-clientaccessserver servername -AutodiscoverSiteScope $null 

A five minute fix resolved an annoying problem for the end users.