Shivering on the 49th Parallel
Tuesday, 20 March 2012
First post of the new year! also can't be arsed to install WL Writer so doing this in the web form. blech. :) One of my "projects" for 2012 is to suss out DirectAccess, a transparent "VPN-less" secure connection back to the mother ship from a roaming corporate laptop. On paper it sounds pretty good, but from a demonstration point of view, it ranks up there with watching grass grow or paint dry. When set up and configured, a laptop (or desktop I suppose) out of the office and off the corporate network can access network resources behind the firewall. Going the other way, IT can centrally control corporate laptops out in the field via Group Policy, WSUS and other technologies. To give a demo, you'd take your laptop off-campus, fire it up, log in... and... use it... not much of a demo :) the stuff going on behind the scenes is interesting, but not for the average person. My engine, however, gets running. I ordered up an HP Microserver last month to try this out on. I suppose I could have installed 2008 R2 on any old computer kicking around, provided it had two network ports on it, but I also wanted to do a hands-on with this little server. The HP Microserver is ridiculously cheap for what it is: an HP ProLiant server. it's about half the size of a breadbox and has four non-hot-swap SATA drive bays, two memory slots, a PCIe x16 and and a PCIe x1 half-height slot, a 5.25" drive bay for an optical or tape drive and one large low-rpm fan on the back so it's really quiet. All that for about $400. I bumped up the price somewhat by doubling the RAM and adding a server NIC card to get a few more network ports on it, but it was still under $1000. Putting a copy of Windows Server on it is where most of the expense comes from. Since this is a test, I put a TechNet/MSDN copy on it and fired it up. There are a lot of pre-requisites for setting up DirectAccess including a good CA/PKI setup, and probably the most difficult part: 2 consecutive public IP addresses that don't end in 09-10. I've got all that covered now, so my next step will be to make some changes to Active Directory, my edge firewalls and then I can try it out!
Tuesday, 20 March 2012 08:28:53 (Pacific Standard Time, UTC-08:00) | Comments [2] | Active Directory | Hardware | Microsoft | Networking | Servers | Windows#
Tuesday, 07 June 2011

Last year I set up a Windows Server 2008 Core server. It was a Hyper-V virtual machine, it was minimum-spec, it didn’t do much other than be a second Domain Controller on the network so I hardly ever had to interact with it. Based on that criteria, and because I wanted to see what it was like, I installed Windows Server 2008 Core.

Windows Server 2008 Core if you’re not familiar is a Windows server with no windows: when you log in, you get a command prompt, and that’s it.

Configuring it after installing was a bit of a bear, because instead of clicking anything, you had to learn, know and type the commands into the terminal, along with all the arguments/switches. I got it set up, configured, joined to the domain and then promoted to be a domain controller and that was pretty much it. I set it up so that I could use Remote Desktop to connect to it, but what I really wanted to do was use the Server Manager on another server to connect to it and manipulate it that way.

I found out the hard way that you can’t really do that. I did find a piece of software written in Visual Basic called CoreConfigurator which created a text-menu-based configuration helper and it was pretty good. They also had a Version 2 which was written in Powershell that had a bit of a GUI to it… but it wasn’t compatible with Windows Server 2008 (the Vista server, if you will) only Windows Server 2008 R2 (the Windows 7 server). I pretty much dropped it after that, since it was running and I didn’t need to do anything to it.

Eventually I upgraded it to Server 2008 R2 when my licensing allowed me to and then I could use CoreConfigurator V2.0. Remote management still wasn’t working, despite the server’s command-line status updates to the contrary. Again, it was working and I had more important things to do.

Today I was trying to track down something (seemingly) entirely unrelated. Some clients could access a DFS share on the domain, and others could not. I followed the trail to the Domain Controller (DC1) and checked DNS services, and they were all fine. I then looked at DC1’s DNS servers and it was pointing at DC2 (the Server Core) so I opened it up and checked it out. I thought to myself “Wouldn’t it be nice if I could control DC2 with the Server Manager on DC1?” so I decided to take another run at it.

On DC2 I entered winrm quickconfig to see what was configured. As expected, it said:
WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

So I tried “Connect to another computer” in Server Manager and… bonk. “Server Manager cannot connect to server_name. Click retry to try to connect again.” opening the details tab had more detail, but it’s pretty much all gibberish even to me. “Connecting to remote server failed with the following error message: The WS-Management service cannot process the request. The resource URI ...://schemas.microsoft.com/powershell/Microsoft.ServerM... was not found in the WS-Management catalog. The catalog contains the metadata that describes resources, or logical endpoints.” Right.

I started with the error code, and then the hex code and ultimately ended up at a Microsoft KnowledgeBase article that hit the nail right on the head.

Error message in Windows Server 2008 R2 or in Windows 7 when you try to connect to a remote server: "Server Manager cannot connect to <server_name>"

Following this article, I typed sconfig from the command-line on the server core, chose item 4 “Configure Remote Management” and then option 3 “Allow Server Manager Remote Management”. It then re-configured Win-RM (which was already configured correctly) but interestingly added three new rules! It didn’t say what those rules were, but after restarting the server (because I had to enable PowerShell) I was able to connect to the server using Server Manager from any of my other servers or my Windows 7 laptop.

Tuesday, 07 June 2011 12:35:39 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Active Directory | Microsoft | Networking | Servers | Windows#
Tuesday, 13 July 2010

Last Friday, one of the workers here in the office came over to me and said that he got an error in his inbox about a message that had been delayed. Not permanently, just delayed. I said OK, leave it, it’ll retry again for the next 48 hours and looked into it.

I connected to the Exchange 2010 server and opened Exchange Management Console and went straight to the Toolbox and clicked on Queue Viewer. There they were, pretty ducks all in a row all with DNS FAILURE errors. Huh. Interesting. I saw this happen once before when we were setting the server up. The DNS server it was set to use was offline, so no DNS resolution meant it didn’t know where to send the mail. Thinking this was the case this time, I checked the Network Adapter settings and saw that the preferred DNS server was the other VM “next to” the Exchange 2010 VM and the secondary was set to “my” DNS server here in my office.

I checked my DNS server first, just to make sure the service was running, and it was. I then checked the DNS server that was it’s primary and it, too, was running. Mystery. Nslookup queries failed and timed out even for common domain names. Not good. This was happening on both DNS servers.

I called in a support ticket (this was Friday at 4:00) and found out that the Exchange SysAdmin was on vacation and not back until Monday, and he was being covered by another Exchange SysAdmin on East Coast time. She called me back about 20 minutes later and we worked on it for a good 40 minutes with no resolution. She figured that since the DNS server was rebooted, it had been unable to contact the

PDC role holder and authorize/activate itself and that there must be a problem with the VPN between my network and hers.

This seemed like a valid diagnosis, as the other Administrator here at work told me that our router had been failing every 30-40 minutes, but recovering after a minute or two and was obviously dying. Yikes. This caused a little panic as ALL my sites use the same router/firewall and they’re discontinued and I hadn’t yet created a contingency plan to replace them.

She escalated the ticket up to tier 3 networking support, who tested the VPN and said that everything was up on their end, but they couldn’t ping my side of the VPN, therefore there was a problem with the VPN and it was on my end. (naturally). I don’t know too much about the router/firewalls we use here, I’ve been slowly learning as I went, but diagnostics and troubleshooting was beyond the scope of my knowledge beyond “well the blinky light is green, not red, so it’s up”.

Further compounding the matter was that this VPN was temporary, because we were switching it on Monday from an Internet VPN to a private, routed DSL connection into their MPLS network. That ADSL modem was plugged in to power and phone, but not into the LAN as it was just for testing.

At some point over the weekend, one of the emails from their networking people said that they could ping as far as 192.168.0.252 but no further. This was when the light bulb went off in my head. .252 is the address of the new ADSL router, NOT the VPN endpoint! Their network techs were trying to reach my network via a device that was physically unplugged! I thought it was odd, since I was connecting from home via VPN through the same device and it was up.

Monday came and I plugged the DSL modem into the LAN and disabled the Internet VPN connection from my network to theirs, created a new route for all traffic destined for their network to use this new gateway and everything seemed to be working. Outlook clients in my LAN segment were connecting via the MPLS network, verified by the IP addresses on a traceroute… I could Remote Desktop the virtual servers in their network… everything seemed to be working, but their network guys could still not ping my LAN from the MPLS gateway, even though I could ping back to my network from the Virtual servers (which was the important part anyway) so that left me with the DNS problem, which was still ongoing and some people were now starting to get NDRs because the 48 hours had timed out.

I started with my own laptop, and did an nslookup query. request timed out. Damnit! I checked the DNS server, the service was running, I restarted it, it still failed. I looked at the event log and there were a bunch of “DNS server encountered an invalid domain name” errors, but the errors were coming from all these weird IP addresses that were not in my network. I then thought that perhaps it was the forwarding that wasn’t working, based upon a few results that came up when I searched that error message online. I checked the forwarders on my DNS server and found that they were set to use two Shawcable.net servers, one of which resolved to a hostname and both of which did not respond to an nslookup query. How on earth did I end up with two (seemingly) random Shaw Cable DNS servers for my forwarders when I have a Telus ADSL connection in this office? that could explain why they didn’t respond; my IP address wasn’t in the Shaw Cable network!

I changed the two forwarders to 208.67.222.222 and 208.67.220.220 which is OpenDNS. I then restarted the DNS Server service and BAM! nslookups all worked. I then went back to the Exchange server and tried again. Still failed. OK, I have an idea of what’s going on now, so I connected to the DNS server there and checked it’s event logs. Similar messages, different addresses. I opened the DNS snap-in and went right to the forwarders. The two forwarders on this server were two Telus servers! This was a co-located (sort of) Virtual Server within an ISP, so how did I end up with Telus servers there?! I changed those two forwarders to OpenDNS and restarted the DNS Server service and as I was opening a command prompt window on the Exchange 2010 server to try an nslookup again, I could see the emails in the retry queue (which was still open) begin to flow out. I tried nslookup queries on a couple domain names that I knew were in the retry queue and they all answered lightning fast as non-authoritative responses.

SO in the end, I figured it out myself, but the million-dollar question that I can’t answer is HOW did my local DNS server get a Shaw DNS server as a forwarder, and how did the VM DNS server in the datacenter get a Telus one??

Tuesday, 13 July 2010 08:44:13 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Active Directory | Mail Server | Microsoft | Networking | Servers | Windows#
Thursday, 28 January 2010
About a week later the server died. I diagnosed over the phone that it was the power supply and rather than travel over for 5 hours & a ferry ride and then have to stay over just to replace a $100 power supply, I had them take it to a local computer store and have them replace it.
Thursday, 28 January 2010 11:23:10 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Active Directory | Hardware | Microsoft | Servers#
Search
Archive
Links
Categories
Admin Login
Sign In
Blogroll
Themes
Pick a theme: