What is this? I don't even...
Although I missed World IPv6 Day, I was bored the other night and decided to finally setup an IPv6 tunnel. To do this, I registered a free account with Hurricane Electric’s Tunnel Broker. The process was a breeze and in no time I had a regular tunnel created. From there, it was all up to the Dlink router.
A few notes:
- Make sure you have the latest firmware for your DIR-825 Rev. B. At the time of writing, it’s version 2.05(NA).
- You will need to enable “WAN Ping Respond” – this can be found under Advanced -> Advanced Network. You can safely disable this after you finish complete the process and your tunnel is working. This is needed so that Tunnel Broker (TB, from here on out) can confirm your public-facing IP address and link it to your tunnel.
So, that out of the way, once Tunnel Broker has confirmed your tunnel is available, login to your router and do the following:
- Under the main Setup tab, click IPv6.
- Click the Manual IPv6 Internet Connection Setup button. Do not use the wizard.
- For the IPv6 CONNECTION TYPE, choose IPv6 in IPv4 Tunnel.
- In the Remote IPv4 Address box, enter the Server IPv4 Address provided by TB.
- In the Remote IPv6 Address box, enter the Server IPv6 Address provided by TB.
- The Local IPv6 Address is the Client IPv6 Address from TB.
- Under the IPv6 DNS SETTINGS heading, choose Use the following IPv6 DNS servers and enter the Anycasted IPv6 Caching Nameserver provided by TB in the Primary IPv6 DNS Server box (TB did not provide me with a secondary DNS address).
- Finally, uncheck Enable DHCP-PD under the LAN IPv6 ADDRESS SETTINGS heading.
- Leave the settings under the ADDRESS AUTOCONFIGURATION SETTINGS heading as their defaults.
- Click the Save Settings button at the top of the page and let the router do it’s thing. It will take some time to ‘measure the internet connection’ – this is normal.
You’re almost done. At this point, if you go to the Status tab and choose IPv6 from the options down the left side of the page, you should see the TB information you entered, and Network Status should say Connected.
The rest of the work depends on your operating system. I use Windows 7 on my main PC, which natively supports IPv6 (as does OS X and most *nix distros). As IPv6 is enabled by default, I simply had to open an Elevated Command Prompt and type:
ipconfig /release
ipconfig /renew
After it finished thinking, ipconfig spat out the new network configuration which included the correct IPv4 and IPv6 addresses. I opened Firefox and browsed to http://ipv6.google.com – success! Everything works! You can also confirm that IPv6 is working by using the nslookup tool from a command prompt like so:
C:\Users\Laslow>nslookup
Default Server: ordns.he.net
Address: 2001:470:20::2> xbox.com
Server: ordns.he.net
Address: 2001:470:20::2Non-authoritative answer:
Name: xbox.com
Addresses: 2a01:111:f009::3b03
65.55.42.140>
As you can see, the IPv6 nameserver came back with an IPv6 AAAA record (2a01:111:f009::3b03) and an IPv4 A record (65.55.42.140) for xbox.com.
The last time I wrote about NX Domains, it was because I noticed that Rogers wireless was hijacking them on my phone. Now, it appears that Shaw Cable is doing the same.
I use OpenDNS, so I’m used to search pages coming up when I mistype URLs, however that is something I’d opt’ed in to. You can imagine my surprise when, after mistyping a URL, I was directed to this instead:
http://assist.shaw.ca/shawcaassist/dnsassist/main/?domain=www.example.com
(original URL redacted).
It appears that, even if you aren’t using Shaw’s DNS servers they are still checking your DNS requests and, in the case of NX domains (at least – they could technically do this for any traffic), hijacking the result and forwarding your browser to their page instead.
I’ve sent a barrage of messages to Shaw’s PR team on Twitter, but haven’t had a response yet. I’ll update this article when (or if) they reply.
For the time being, though, it appears you can opt-out of the ‘service’ using this page: http://nxr.shaw.ca/optout/
Update: I’ve had a reply from Shaw saying “We do not modify any DNS traffic going to our customers from other sources”. They’re currently looking in to the issue apparently, so another update will be in order when I hear back.
Additional Update: I received a reply from Shaw asking me to do some further troubleshooting, all of which would have been useless (eg, using the ‘dig’ and ‘nslookup’ commands to confirm my DNS settings and what the NX response was), however as I opted out of the ‘service’ I can’t actually complete the steps as everything is working correctly. Additionally, there doesn’t appear to be a way to opt back in to the ‘service’, so that’s also a bust. I guess I won’t be getting an answer as to what happened. Also, I was linked on Reddit Canada.
Years ago, long before I started working at my current job, management launched a new contract in a office building just across the street. At the time, wireless network connections were still in their infancy and not to be trusted, so the new office was set up with a pair of servers, a nice new Active Directory Forest and Domain (DomainB), and a VPN to access resources on the primary network, DomainA.
Fast forward to three years ago, just before I was hired. The then-sysadmin was getting flak for the VPN being slow, so he installed a pair of wireless routers on the roofs of the buildings and linked the two networks. However, instead of getting rid of DomainB, he simply left it in place.
Fast forward to now. Due to cost issues, the contact in the remote office was physically moved to our main building. As such, their network equipment and servers came with them, which created cramped quarters in an already cramped space. As such, I set about doing what should have been done years ago – migrating users from DomainB to DomainA.
There was a group of client computers that needed to go through a round of updates anyways, so those were simply re-imaged and joined to a separate, restricted network (DomainC) used for our clients only (this had been another pet peeve of mine – due to costs, the clients in that office were put on the same network and although they had their permissions restricted, it was still a concern in my mind). The main problem, though, was the staff workstations. Not only were they setup on DomainB, put PrimaryDC.DomainB was also an Exchange 2003 server, and TertiaryDC.DomainA was our primary mail server running Exchange 2007. The first step was to manually export the mail for the twelve staff members and create their DomainA accounts, and then get them setup on the DomainA Exchange server. Once that was up and running, the Exchange 2003 install was shutdown. Although it took a while to manually transfer the mail by exporting to .PST files and then importing it again, it was the cleanest way to do the move (and also encouraged users to clean out their mailboxes).
The last step was to actually get the users logging in to DomainA rather than DomainB. That’s where ADMT (Active Directory Migration Tool) comes in.
ADMT comes in a few ‘current’ versions. 3.0 if the server it’s running on is Server 2003, 3.1 if it’s Server 2008, and 3.2 if it’s Server 2008 R2. The source domain (B) was running on Server 2003 boxes, but the target domain (A) was running mostly on Server 2008 boxes, so I installed ADMT 3.1 on one of those.
After getting it installed and playing around with it on a test VM, I learned a few things that helped me get all of the staff workstations migrated with minimal issues:
- Setup a Two-Way Trust between the domains first, but be aware that if users are already authenticating on both domains by using store credentials, that may break unless you also setup permissions for users of both domains on effected shares.
- Double-check your DNS configuration. If both domains have separate Forward Lookup Zones (which they probably do), make sure that the DNS servers in both domains are setup to perform Zone Transfers between each other, and then check to make sure that all A and PTR records are actually correct and current.
- Make sure that the user you are logged in to on the server running ADMT is in the Domain Admins group on the target domain, and the Administrators group in primary DC on the source domain.
- Change the DNS servers that the computers to be migrated are using to the servers on the target domain. This is important, or after the computer migrations are complete you may run in to issues when logging in (for me, Active Directory decided to continually lock out user accounts of migrated users because of a missing A record in the source domain’s DNS zone).
- If you have any local firewall software running on the workstations that are to be migrated, either temporarily disable it or add exceptions for the Netlogon Service, File and Printer Sharing, and Windows Management Instrumentation (although the last may not strictly be needed – it was hit-or-miss for me).
- Run the following command on the workstations that you’re migrating: net localgroup “Administrators” “DomainAdomain admins” /ADD (changing DomainA to your target domain). This is important, as local admin rights are needed for the computer migration steps.
- If users from your source domain are using resources on your target domain and using stored credentials to authenticate, delete those stored usernames/passwords from the workstation (in most cases, open Control Panel, then User Accounts, and click ‘Manage Network Passwords’ on left). Then, once you have migrated the user accounts, give those accounts permission to access the required resources.
- During the migration, if you are trying to migrate a computer account and you continually receive an error like ERR2:7666 Unable to access server service on the machine ‘computer.domain’. Make sure netlogon and workstation services are running and you can authenticate yourself to the machine. hr=0×80070005. Access is denied., and you’ve run the command above on the machine to give Domain Admins from the target domain local admin rights, you may need to remove the computer from the source domain, rejoin it to the source domain to re-establish the trust relationship, and then try the migration again.
- After the migrations are done, make sure to go back to the DNS servers on your target domain and verify that the migrated computers’ PTR records reflect the new domain suffix (eg, changed from ‘workstation1.domainB.’ to ‘workstation1.domainA.’ (and leave the trailing . in, or you’ll have trouble!).
And that’s it! ADMT worked like a charm, and after using it to migrate and merge user accounts, and then migrate the computer accounts, everyone was off DomainB with out the hassle of needing to manually join DomainA and reconfigure the user accounts. By performing both the user account and computer account migrations, once the process was done users just had to login to their computers using ‘DomainAUsername’ instead of ‘DomainBUsername’ and everything was left exactly like it had been, right down to the desktop wallpaper.
And now I’m free to decommission two old servers.
While updating a set of public computers to have private file shares (making use the Home Directory account property in AD to automagically map the drive), I ran in to an issue with folder redirection. I wanted to redirect all of the standard personal folders (Documents, Pictures, Music, et al…) to the same share, so I setup folder redirection in a Group Policy Object to point those folders to the users home drive (for this example, we’ll say drive Z: was mapped to \serversharefolder).
I gave the user full rights to the share, and assigned it Owner status as well (all through the Security tab, as standard), and then configured the GPO as appropriate. After rebooting the client computer, however, I checked the Documents folder only to find that it was still pointing at the default location. A quick peek in to Event Viewer revealed the following error:
Failed to apply policy and redirect folder “Documents” to “\serversharefolder”.
Redirection options=0×80009211.
The following error occurred: “Can not create folder “\serversharefolder”".
Error details: “Access is denied.”.
Which was very strange indeed, as a brief check confirmed that yes, the domain user did in fact have full access to both the folder and the share.
Then, something I saw (and stupidly, ignored) when setting up the GPO came back to me. I fired up the GPO editor and and browsed back to the Documents folder redirection section (User ConfigurationPoliciesWindows SettingsFolder Redirection). After double-clicking the Documents option, and then switching to the Settings tab (shown below), I noticed the top two boxes (“Grant User Exclusive Rights to Documents” and “Move the Contents of Documents to the New Location”) were selected by default. Given that this was an ‘Access Denied’ error, I figured one of these two settings must be at fault, so I unchecked them.
After rebooting the client computer, the Documents folder redirected to the Home Drive as expected.
Here’s where it gets stupid, though. On the ‘Target’ tab in the Documents properties window (visible in the screenshot above), if you have the ‘Target folder location’ set to ‘Redirect to the users home directory’, it explicitly adds a note that says “This settings ignores the value of the ‘Grant User Exclusive Rights to Documents’ option on the settings page.
Apparently not, Microsoft. Apparently not.
TL;DR Version: If Folder Redirections aren’t applying correctly, Event Viewer is showing ‘Access Denied’ messages, and you’re using Home Folders specified in the user account, disable ‘Grant User Exclusive Rights to Documents’ option on the settings page of the GPO.
That’s one heck of a long post title, but it at least describes the issue. Here’s the setup:
- 1x Windows Server 2008 R2 with Hyper-V/AD/File Server roles, and two shared folders. Server has dual onboard NICs, one with full access to the client network below, the other to a separate network to allow the server to be managed remotely (no gateway configured on this NIC).
- 18x Windows 7 x86 clients
- Standard network setup (read: no VLANs, bridging, etc…. Just one network switch).
The previous server used by these clients worked perfectly. However, upon replacing the server with the one above, my users began noticing an odd issue. If they copy one or more files/folders to a share that is visible to all of the computers, the file(s) don’t immediately show up on all of the computers – usually 3/4 of the computers will see the file(s). On the 1/4 that don’t, users either have to wait ~10 minutes before the files will appear, or they can reboot to force a refresh. Simply pressing F5, or right-clicking in the shared folder and choosing ‘Refresh’ doesn’t work – only waiting or rebooting does.
In terms of a solution, I’ve seen a number of suggestions, but none seem to work. The server has dual-onboard Broadcom Gigabit NICs, and a number of forum posts have suggested disabling Checksum Offload and Large Send Offload, but this made no difference. Neither did disabling IPv6 on the client and server side. Disabling firewalls on the client and server side made no difference, nor did this post suggesting a few registry settings to change.
What did fix the issue, though, was disabling SMB2. Once all of the clients were connecting using the old SMB protocol the issue disappeared. I have no idea why SMB2 is an issue as I haven’t take the time to troubleshoot further with SMB2-specific settings, however this at least has things running normally.
TL;DR Version: If you have clients connecting to a Windows Server 2008 R2 box and the contents of file shares aren’t refreshing immediately or until reboot, disable SMB2 on the server.
When you manage a *nix-based server, there are a few general guidelines that most admins follow; Doing things like setting a strong root password, changing SSHD to a non-standard port, and setting up logging are usually firsts. However, if you’re on a VPS, you may run in to a few issues (note that these instructions are for CentOS 5.x and may vary depending on your distro).
For example, when I was setting my the nice new VPS that I’m running this site from I attempted to enable IPTABLES logging to monitor attempts to get to the standard SSH port (22), and the port that I actually use for SSH (I won’t post the real one, but for the example I’ll use port 1234) with the following lines in “/etc/sysconfig/iptables”:
<Snip other rules>-A INPUT -m state --state NEW -p tcp -m tcp --dport 1234 -j LOG -m limit --limit 20/m --log-level warn --log-prefix "SSH Attempt on port 1234: " -A INPUT -p tcp -m tcp --dport 1234 -j ACCEPT<Snip even more rules>-A INPUT -p tcp -m tcp --dport 22 -j LOG -m limit --limit 20/m --log-level warn --log-prefix "Dropped SSH on port 22: "-A INPUT -j DROP
Note that you need to add the LOG lines before the ACCEPT and DROP lines. Only 20 lines will be logged per minute to prevent file sizes from going nuts in case of an attack.
After restarting IPTABLES with service iptables restart, I made a few access attempts and checked /var/log/messages — no log lines appeared, though. Then I realized I was missing something.
In “/etc/syslog.conf” I had to add the following to the end:
kern.=warn /var/log/firewall
I opted to log to firewall instead of messages simply to keep the file clean.
I restarted SYSLOG with service syslog restart, made a few more attempts, and still nothing was appearing in “/var/log/firewall” or “/var/log/messages”. However, typing dmesg showed the relevant lines:
SSH Attempt on port 1234: IN=venet0 OUT= MAC= SRC=10.0.0.1 DST=10.0.0.2 LEN=48 TOS=0×00 PREC=0×00 TTL=116 ID=28979 DF PROTO=TCP SPT=35291 DPT=1234 WINDOW=8192 RES=0×00 SYN URGP=0
So I knew that SYSLOG was working, however it wasn’t going all the way. Then I decided to see if KLOGD was running:
[root@vps ~]# ps aux|grep klogdroot 13632 0.0 0.1 7188 788 pts/0 S+ 00:07 0:00 grep klogd
So that means that KLOGD isn’t running, which is the cause of the problem! I checked “/etc/rc.d/init.d/syslog” and found that the KLOGD lines were commented out, as such:
<snip>passed klogd skipped #daemon klogd $KLOGD_OPTIONS<snip>passed klogd skipped #killproc klogd
In the “start()” and “stop()” areas respectively. I simply removed the “passed klogd skipped #” parts, saved and ran service syslog restart and presto, KLOGD was up and running:
[root@vps ~]# ps aux|grep klogdroot 7542 0.0 0.0 3808 424 ? Ss Oct11 0:00 klogd -xroot 15402 0.0 0.1 7188 788 pts/0 S+ 00:13 0:00 grep klogd
I made a few more connection attempts and verified that now everything was working correctly:
[root@vps ~]# cat /var/log/firewallOct 11 23:47:06 vps kernel: SSH Attempt on port 1234: IN=venet0 OUT= MAC= SRC=10.0.0.1 DST=10.0.0.2 LEN=48 TOS=0×00 PREC=0×00 TTL=116 ID=28979 DF PROTO=TCP SPT=35291 DPT=1234 WINDOW=8192 RES=0×00 SYN URGP=0Oct 12 00:13:03 vps kernel: Dropped SSH on port 22: IN=venet0 OUT= MAC= SRC=110.77.129.166 DST=10.0.0.2 LEN=60 TOS=0×00 PREC=0×00 TTL=45 ID=59383 DF PROTO=TCP SPT=33846 DPT=22 WINDOW=5840 RES=0×00 SYN URGP=0
Done and done! IPTABLES now properly logs to “/var/log/firewall” when someone attempts to hit port 22 or 1234.
TL;DR Version: If you want IPTABLES logging enabled on your VPS, follow the normal steps to enable IPTABLES logging and then make sure KLOGD is enabled in ”/etc/rc.d/init.d/syslog”.
Further Update (06/27/2011): If you have a Dlink DIR-825 router, I just published an article on getting a free Tunnel Broker IPv6 tunnel account working. Check it out! If you have a router that is cable of an IPv6 over IPv4 tunnel, or just want to use a single computer, check out Tunnel Broker from Hurricane Electric.
Over the last few days I’ve been attempting to gather information on IPv6 in Canada, and so far the news is grim. Why am I looking in to it? Well, there have been a number of articles posted lately about the impending end of available IPv4 addresses and the sorry state of IPv6 addoption, and I wanted to check in on my local ISPs and see if any of them are preparing for this. The short answer? No.
My region has two primary ISPs – Telus and Shaw Cable. I did a quick Google search to see if either had made any announcements about IPv6 readiness, and I ended up with no relevant results. In fact, a search of “IPv6″ on the domain shaw.ca only returns results on user hosted pages. Searching Google for “IPv6 Telus” only comes up with one close match – this PDF document that’s basically a beginners guide to IPv6.
So, I opened a ticket with my ISP (Shaw), and tweeted at their customer care guys. I also tweeted at Telus’ customer care. Here’s what I got back.
Telus tweeted back pretty quickly:
@laslow We don’t have any news on implementation of IPv6. It would make sense that everyone will switch eventually. -Trevor @TELUSSupport
I replied, and they came back with this:
@laslow We’ll try and help where we can but no real info on this. Hope your day goes well!
Well, that was rather uninformative.
Sean from Shaw Customer Care also replied rather quickly on Twitter:
@laslow hey man, no word on IPv6 yet, hopefully sometime in the near future though.
Shortly after, I received the following reply to the ticket that I opened with Shaw:
Hello [Laslow],
This is [Agent], thank you for your e-mail.
At this time there is no set date that IPv6 will start to be used. As soon as address’s have ran out with IPv4 then everything would be switched over to the IPv6. Kind of like how in B.C. not including the lower mainland we have been using the area code 250 for years. There are no longer numbers available with the 250 area code so they moved to 778 area codes. It will be similar to this when IPv6 is released, sorry we have no further information for you at this time on this.
So in short, Shaw’s plans are to wait until they’ve run out addresses, and then worry about what to do next. I don’t know about you, but I’m definitely feeling more confident that Shaw will be able to connect me to IPv6-only services in the next, you know, ten years or so.
Honestly, though, there are a number of ISPs in the states that already have public IPv6 tests available (Comcast, for example) – why is Canada so far behind?
If anyone reading this works for Telus or Shaw and has more information on their progress towards IPv6, please leave a comment or send me a tweet – It would be nice to know if there are at least plans in place rather than just a sense of “we’ll cross that bridge when we get there”.
Updated (11/29/2010):
I contacted Shaw, Telus, and Rogers via twitter again and received the following responses (still waiting to hear from Shaw):
@laslow At this time we do not have any information/news – Ryan with @TELUSSupport (Direct link to tweet)
@laslow Hi Laslow. I have no info – but can ask around tomorrow. I’ll get back to you if I get an update. (via @RogersElise - Direct link to tweet)
I’ll post any additional information I receive as I get it.
Updated (11/30/2010):
Shaw responded this morning with the following (still no additional information back from Rogers):
@laslow yes, it’s in the pipeline, however, no confirmed release dates yet. (via @Shaw_Sean – Direct link to tweet)
So we have at least one ISP that will willing to publicly state that they have plans to deploy IPv6. Still, solid details would be welcome.
Updated (02/01/2011):
You can check to see if your ISP has IPv6 Prefixes using this site. If they do (I can confirm Shaw and Telus do, haven’t checked others yet), it shows that they have IPv6 connectivity with the rest of the world. If not…well, it might be time to panic. I bugged Shaw again via Twitter about IPv6, and got this response:
@laslow I honestly have no idea, but I’ll make sure you’re the first to know should I hear something.
So, I’ll update again when I hear more.
An HP P4015dn - This morning, the bane of my existence
Note: Make sure to read over the comments on this post – there is some excellent advice there as well.
Windows 7 has been very good to me so far, but this morning I was literally pounding my desk in frustration over a printer issue. I just received two brand-new Dell Optiplex 780′s and was in the process of configuring the printers on them when I happened across this little message:
Windows Cannot Connect to the Printer: 0x0000007e
Now here’s the situation. The computers are running Windows 7 Professional x64. The printer (an HP P4015dn) is connected to a Windows XP x86 machine and shared normally. Of all of our printers, this is the only one directly shared with a computer due to a wiring issue I have yet to correct (although now I’m going to make an effort to fix it). I have several other computers running XP and Vista (x86 and x64) that already print this computer without issue, so I was rather stumped. Then I realized I had attempted to install the Vista x64 Postscript drivers instead of the Windows 7 ones.
Unfortunately, Windows 7 no longer provides a dedicated ‘Printers’ control panel, and the ‘Devices and Printers’ one doesn’t have a Server Properties option to let you manage installed drivers. So, I stopped the print spooler service and manually deleted the drivers from C:\Windows\System32\spool\Drivers. When I tried to re-add the printer, though, I got this message:
Windows Cannot Connect to the Printer: 0×00000006
Hmm. Google wasn’t much help, so I went to an old standby – I mannually added the network printer by choosing to create a local port (silly, I know). Here’s how to get this working:
- In the Devices and Printers control panel, choose Add a Printer.
- In the new window, click Add a local printer.
- On the following screen, select Create a new port, and then choose Local Port from the drop-down list and click Next.
- When asked to enter a Port Name, use the full path to the printer. For example, if your printer share is called Dave and is a computer with the name PrintSrv1, you would enter \PrintSrv1Dave as the Port Name. If you receive an error saying The network path was not found, check the computer name and share name, then try again.
- You should be asked to install a driver. Manually download the correct driver (in this case, the HP Universal PostScript driver worked for my HP P4015dn) from the manufacturer’s website and extract it to a folder on your computer. Then click the Have Disk… button in the Add Printer wizard and point it to that folder, then click OK and Next.
- Wait for it to install the driver.
At this point, the printer should be installed and functional. Print a test page to make sure everything worked alright, and then do a little dance (as long as no one is looking)!
For a while now I was having problems opening Word and Excel (2007 and 2010) documents on my work computer. Most of the time everything would work, but every now-and-again I’d go to open something and Word or Excel would report that it was “Downloading <filename>”, and simply get stuck. Although I could click the little ‘X’ to cancel and close the window, the process for either Word or Excel would stay active, and any attempts to kill it would fail. In the end, I’d have to hard power off the computer to get it to shutdown, and then do a cold boot.
Oh, 'Downloading' message, how I hate thee.
I wasn’t really bothered by it until a few of my users started reporting the same problem. I had a look in to it, and after a lot of fiddling, came across two Microsoft Knowledge Base articles that eventually led me to a solution.
By adding the registry value from the first KB article linked above (EnableShellDataCaching), and by removing the Group Policy object that was creating a persistent drive mapping and replacing it with a login script (below) to map the drive, I haven’t had any further reports of the problem.
REM Login Script – Paste these lines in to a batch file, and add that .bat file to a GPO
net use z: /deletenet use z: \10.0.0.100share
Note the use of the IP Address, rather than the Fully Qualified Domain Name (FQDN) – this was essential to getting things working in the end.
