Glo Networks Technical Blog (Glo Blog)

If you’re not familiar with what IPv6 is, it’s the next generation Internet Protocol. In broad terms, if we don’t all start using it we’re heading for a world where communicating directly between devices gets a little trickier (if you want to know more, check out our (rather long) previous blog post entitled “The sky is falling on our heads; We’re running out of addresses“).

As you can probably imagine IPv6 is generally considered a Good Thing(TM), by many technical people. After all, we don’t want to make our lives harder, do we?

The problem is uptake has been slow. The first official specs were released in 1996, but work on defining the protocol is tracable back to 1992. That’s a long time ago in the computer industry. The main issue was a chicken and egg problem; why bother upgrading your network when no one uses it? And no one will use if it there’s no reason (read: content). The other problem has been sometimes you can get an IPv6 address without having an actual IPv6 network, and sometimes it won’t work. That’s the non-technical explanation.

These 2 issues are whats caused IPv6 to really stutter.

However last year, on June 8th 2011, major websites and services enabled IPv6 by default to gauge the impact. It turned out that most of the potential problems weren’t really problems for over 99.9% of their users.

So this year, on June 6th 2012, major players who rely on the Internet, and produce hardware and software to access the Internet, will be enabling IPv6 permanently including, but not limited to;

• Akamai
• AT&T
• Cisco (& Linksys)
• Comcast
• D-Link
• Facebook
• Free Telecom
• Google
• Internode
• KDDI
• Limelight
• Microsoft Bing
• Time Warner Cable
• XS4ALL
• Yahoo!

So where am I going with this?

Glo Networks are proud to announce that we are now able to provide native IPv6 accessible web hosting right now. We’re working on the rest of our services at the moment, but we feel this is an important first step. One of our website host boxes is happily server on IPv6 -
dig -t AAAA stem.glo-net.net

; <<>> DiG 9.7.3 <<>> -t AAAA stem.glo-net.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;stem.glo-net.net. IN AAAA

;; ANSWER SECTION:
stem.glo-net.net. 3600 IN AAAA 2a01:4f8:121:2322::defa:ced

;; Query time: 44 msec
;; SERVER: 213.133.99.99#53(213.133.99.99)
;; WHEN: Wed Jan 18 16:13:07 2012
;; MSG SIZE rcvd: 62

If you already host your site with us and want access either open a support ticket on GloHelp or give us a ring.

If you don’t already host your site with us, feel free to give us a ring.

If you want to talk about IPv6 enabling your corporate office network, again feel free to get in touch.

Want to know more? Check out world www.worldipv6day.org, www.worldipv6launch.org.

Posted by Karl in Cool Stuff, Networking | No Comments »

For those of us Exchange admins who aren’t fully up to date with Exchange 2010 service packs (for whatever reason – don’t berate us) and have slowly been getting annoyed with an ever increasing amount of mailboxes that get automapped in Outlook 2007 and 2010 can rejoice. One of our staff spent 10 minutes reearching, understanding and writing a bit of Powershell to resolve the issue en-bulk.

Just run the following under a Powershell instance with the Exchange modules loaded (i.e. the Exchange Management Shell).

foreach ($u in $(Get-User)) { Write-Host "Clearing the msExchDelegateListLink for $($u.distinguishedname)"; $ad = [adsi]"LDAP://$($u.originatingserver)/$($u.distinguishedname)"; $ad.msExchDelegateListLink.Clear(); $ad.SetInfo(); }

Be aware that if you do this, all auto mappings for all users will get removed. This may not have the desired behaviour as some users may be relying on an automapped account. It should be feasible to alter this as required, as it’s pretty damn simple!

As with all things, do this at your own risk, we accept no liability, yadda yadda yadda.

If you’re curious (and lets face it, if you’re modifying the Active Directory en bulk, you should be!), basically what this does is loop over all users, and clear all values against their Active Directory account msExchDelegateListLink attribute. This attribute is where the automapping gets written to.

As an example imagine 2 users, Bob and Alice. Bob is an Exchange admin and at some point was granted full access (with permission, naturally) to diagnose a problem with Alice’s mailbox without having to disturb her too much directly. Bob will now be added to Alice’s msExchDelegateListLink attribute. It’s this entry that needs to be removed.

Apparently in SP2 there is the facility to disable automapping, at the time of adding the relevant permission; the shiny new “-AutoMapping” argument to Add-MailboxPermission. As with many things Exchange 2007 and newer, it’s just a facility available at the Powershell console, for now. And you know what? We’re ok with that.

Posted by Karl in Applications, Cool Stuff, Scripting, Servers | No Comments »