A couple weeks ago I did some research to see if I could save money by switching to AT&T U-verse service for Internet and TV service. The difference between U-verse and DSL is that DSL combines the POTS and DSL signals at the frame (local office), while U-verse uses the fiber optic cables in the street which it converts to 2-wire copper at the street junction box nearest to you. This means that there is no distance limitation for U-verse your area just needs to be wired with fiber optic cables.
So, on Tuesday, March 17th, 2009, they came out to install the service after being assured that:
- If I did not like the service I would be able to switch back to my old service (POTS with DSL).
- The TV service would not have any impact on my Internet service.
- My DSL service would be available until I decide to disconnect service.
In actuality, none of the above was true. 30 minutes before the installation tech called, my residential DSL service was disconnected. When he called, he said that it is not possible to have both DSL and U-verse service at the same address, but I later learned that there is no logical reasoning for this as I have 4 CAT-5 wire pairs wired in the building and U-verse only requires 2 wires. I did find that once an address is labeled with U-verse service, everything at that address becomes U-verse or dies. The later being the nightmare.
Prior to this, I had two POTS lines with DSL, one residential and one business. The U-verse service was supposed to be a completely separate and new residential account for Internet and TV service only. Since I was not moving my residential POTS line to U-verse, there should not have been any link between the two, but that is not the way that it was installed. The tech disconnected the DSL at the frame and added the U-verse carrier to my POTS line at the street. This was the beginning of the end.
I told the tech what I had been told and he said that I was incorrectly informed. He said that there is no way to have both DSL and U-verse service at the same address, even though my business DSL line was still working (keyword: was). Since I had no options at this point, I decided to go ahead and convert all of my Internet access over to U-verse ASAP, something that I didn't want to do until I was able to fully test the service.
I spent all of Tuesday and Wednesday trying to setup the 3800HGV-B 2-Wire Gateway to work with my network. Getting outbound connections to work was not really that difficult, but getting inbound connections to work was a completely different matter. Late Wednesday afternoon I called 2-Wire support to find out why the gateway was not allowing inbound server connections. The inbound status section of the gateway had "KILL_<protocol>" item for each server protocol (i.e. DNS, SMTP, POP, etc.), but there wasn't any visible option to remove them.
The guy at 2-Wire told me that they only sell their products to ISPs, who modify the firmware to match their network. A long story short, AT&T screwed up the firmware and blocked all of the server protocols to the DMZ bypass host, which is supposed to bypass the firewall. If you use the gateway's DHCP server to manage IP addresses you have the option to disable firewall intervention for each DHCP client, but Internet servers are usually multi-homed (have multiple IP addresses) and cannot use DHCP. Until this issue is fixed, it is not possible to run servers behind the gateway.
Now on to the TV service. When I first tried it, I thought that it was awesome as it changed channels in less than 1/10th of a second. The HDMI service appeared to be locked into 96Khz digital audio and I didn't get a chance to test if it was true surround sound. The set-top box for TV service is Compact Windows based and looks pretty good. The tech told me that the TV service may impact the Internet service as the total download pipe is 25Mbps, each HD channel requires 7.5 Mbps (max of 2), and my Internet connection was supposed to be an 18Mbps down/1.5Mbps up connection. Do the math.
So, I setup the DVR to record the shows that I watch, all of which are HD. At 8pm on Tuesday, a notice appears on the TV, as the screen goes black. It basically says that I can't watch another HD channel while 2 HD channels are being recorded. The wording is different, but it's no different than how DirecTV works, so I'm thinking that I'll watch one of the channels being recorded. Nope, can't do that....black screen. OK, lets try playing the recording that is currently being recorded. Nope, can't do that either....black screen. Maybe another show that was recorded earlier? Nope, can't do that either....black screen.
I didn't try watching an SD show as SD shows look like crap on a 46" HDTV. It's like watching TV through coke-bottle glasses when you don't need glasses. TV service was out. Internet service was out. So, on Thursday morning I called to cancel service and have my old service restored. Before I tell you how that went, I need to back track a little bit to Wednesday morning.
When I came into the office on Wednesday morning I noticed that my business DSL service was down, but the POTS line was working. I called AT&T support and was immediately routed to AT&T U-verse support. No matter how hard I tried, it was not possible to reach DSL repair directly. As I alluded earlier, once your address is flagged as having U-verse, all services become U-verse. If a service is not a part of U-verse (i.e. DSL) it gets disconnected. So, my business which has the same address as my residence, is now flagged as U-verse. Since DSL is not a part of U-verse, a disconnect order was sent for my DSL service. And since my POTS line is tied to the DSL service, the POTS line had a pending disconnect order as well.
All-in-all, I spent well over 16 hours on the phone trying to get this fixed, but nothing could be done. Once an order is processed, none of the subsequent orders can be stopped. You can try, but all it does is slow down the inevitable as the system physically destroys and releases services. On Thursday, March 19th, 2009, I placed an order for new service while they were still trying to see if anything could be done to end the cascading destruction. I was originally given a March 25th installation date for the new services, then a late afternoon on the 24th date. On Monday morning (the 23rd) I received a call at 9am from a tech who was originally sceduled to fix now broken lines, who said that he would be able to complete the new installation while he works on the repair.
Once the new lines were functional I told him to cancel the repair service as the old IP addresses could no longer be recovered, and I was informed that the repair could not be completed. A new order would need to be placed to get them working. From about 1998 to 2001, this used to be how Pacific Bell (now DBA AT&T) normally did it's business. I had similar experiences back then when they would randomly disconnect service and change the address on my account every 2 weeks. It took me 8 months to get some one to look into why the address on my account was changing, and an entire year to find out that some one had put my DSL number on an Excel spreadsheet of numbers that were to be disconnected.
You would think that AT&T, the largest telco in the world, wouldn't keep repeating the same mistakes over and over, but they do. From previous experience, it typically takes 2-3 years for them to work out all of the kinks in new services and I doubt that U-verse will be any different. Since they weren't even aware of the issues that I discovered over the 2 days that I had service, I doubt that they will be fixed and sooner, which is really sad. Anywho, I just wanted to let everyone know why I had completely disappeared from the face of the Internet for 7 days, and hopefully prevent this from happening to anyone else.
Take it easy,
Bill
After reporting an issue with Adobe Reader 9.0 not working on a fresh install of Windows Vista, I've been waiting for a fix from Adobe. I checked back today and it appears that it was good news that I wasn't able to use the Reader as there is a bug in it that affects all versions prior to 9.1, which was released yesterday. Here is the official post from Adobe:
Security Updates available for Adobe Reader 9 and Acrobat 9
If you have experienced any browser or Adobe Reader crashes while viewing a PDF on the web, especially on any sites that you don't absolutely trust, you may want to perform a complete virus scan of your system(s). This issue goes back to at least version 7, which means that it has been around for years and may have been exploited for just as long.
P.S. Version 9.1 does install correctly and does not crash when opened on fresh installs of Windows Vista.
UPDATE 03/30/2009: The slow network issues came back and progressively became so bad that I was experiencing permanent data loss due to connections timing out. I rebuilt the server last weekend w/o Hyper-V and everything is functioning normally. I came across another post about this issue which refers to the Using Registry Values to Enable and Disable Task Offloading MSDN Library article. Once I'm sure that everything is fine I'll perform a full backup of the system partition and give Hyper-V another try with this new information.
I've been using and/or testing Microsoft's Virtual Server technology (the current version is dubbed Hyper-V) for several years, as I was on the technical beta team. The very first stable version was Virtual Server 2005 R2 with patches that later became available around October/November of 2006. Prior to that the host operating system could lockup or the network connectivity of the virtual instances could completely fail, but once it was working it was a great way to create a virtual DMZ.
Today is the first time that I had a chance to try Hyper-V, as it does not work on any machine with an older processor. Pretty much any system with a processor purchased prior to 2007 is out, and even some of the processors from 2007 won't work. The processor must be a 64 bit processor, and it must support both Hardware Data Execution Protection (DEP) and Hardware Virtualization. All new processors have this support. Gibson Research Corporation offers a free application to test your machine named SecurAble.
If your machine passes the test, you are in for a real treat. Hyper-V is several times better than Virtual Server ever was, but it does have one carry over issue from previous versions that got missed. The issue not only affects virtual machines like the original issue in Virtual Server did, it also affects the host operating system; however, there is a work-around. On the host operating system, you need to Disable all of the TCP Large Send Offload properties of all the virtual network adapters in the Device Manager. If you don't disable this property, all large TCP transactions will burst at an incredibly slow rate (i.e. 1KB/sec).
Fortunately for me, I found the Very slow network performance with Intel NIC when TCP Large Send Offload is enabled post in Microsoft's TechNet forums which discusses the issue. This will most likely be fixed down the road, but this adresses the issue and stops the burst transaction bottleneck. I've only been using it for a couple hours, but I immediately observed a tremendous performance increase when I moved my virtual TFS instance from a host machine running Virtual Server 2005 R2 to a host machine running Hyper-V with 1/3 the resources.
Man, this is one thing that had me going for a while. If you have instances setup to run under a specific user account (i.e. to auto-start on power up), you need to ensure that the user accounts have the proper permissions for all of the virtual files that is uses. This is nothing new and the web interface takes care of the virtual machine file permissions for you, but it doesn't manage the permissions for the virtual network adapters. If your virtual network adapter files are in a different folder, as they should be, this can be a problem as the virtual machine may not be able to read the files.
While tightening up security on my servers, I removed the Users group from the root folder that holds all of the virtual files. The next time that I rebooted one of the virtual machines, all of the network connections on that virtual machine reported "Network cable unplugged". To fix the issue, I gave each of the user accounts that the virtual instances are running under, Read & execute permission to the folder that contains the virtual network adapter files and rebooted the virtual machines. You will also want to ensure that the Network Service account has Modify permissions in order for the web interface to function properly as well.