Tone's Notes

Verizon’s One-Bill service makes several basic mistakes in delivering customer value. The plan is intended to combine the billing for multiple phone services under a single bill. It sounds good, but the potential for aggravation can easily outweigh the benefits of writing fewer checks.

Mistake #1

One-Bill complicates resolving billing issues. The billing cycles of the services combined under One-Bill are not synchronized and the billing details are not brought together under one customer service representative’s control. When you call the customer service number on your bill you’ll eventually get connected to representative “A” who will tell you that the problem has to do with a specific service and will route you to representative “B” at that service. B will offer to review the details with you, but you’ll discover that the bill closing dates and amounts don’t correspond with what you see on your One-Bill statement. This is because One-Bill pretends your billing cycle closes on say the 1^st, while your actual cell phone service billing cycle closes on the 16^th. Given the typical 26 page paper bill, you’ll have to retreat to discussing the billing problem in the abstract. Good luck getting closure that way. Maybe someday they’ll send the bill as a spreadsheet.

Mistake #2

Say you have a family cell phone service with multiple phones and a home phone under One-Bill. Now say you miss a payment and Verizon decides to block service until you pay the bill. What happens? The One-Bill folks block your out-going cell phone service while leaving your home phone working. So you call to restore service but the wireless representative tells you that the block comes from the home phone people and they can’t lift it themselves. How ironic, the people with control block the other service while leaving their own intact! After bouncing between various reps, you’ll be promised that service will be restored. Don’t believe it. Be persistent and stay on the phone with them until your service is really restored. We got promises ranging from 1 hour to 2 days. After the third session of calls on the second day the service was finally re-enabled while we waited.

Mistake #3

The only phone number Verizon will call under One-Bill is your home phone. They claim this is for legal reasons! If you’re like me and use your cell phone for most calls and only check your home phone messages infrequently - or never, when traveling - this is not the best way to be informed of billing issues.

Mistake #4

When you decide to cancel your One-Bill service (to keep your cell phone service simple and manageable) and switch to Vonage for your home phone service ($30/month for unlimited US & Canadian calls) you may discover that you can’t transfer your existing home phone number. Guess what? It’s the One-Bill service on the account that’s preventing the transfer. Cancel One-Bill first. Wait for Verizon to bubble the change through their system. Then transfer the phone number.

Why are these mistakes? Because any layered service should not make existing services more complicated or un-manageable. It must not be more complicated to resolve billing issues. It must not be more complicated to restore service and a problem with one service should not propagate to affect other services.

Hopefully Verizon is working to improve this situation. After all, Verizon’s motto is “we never stop working for you”. Boy does that sound tired when sitting on hold with the 10^th service representative…

The following notes apply to debugging an application running on a Windows XP SP2 box that is intended for stand alone deployment and does not want to (or is not able to) join the same domain as the development machine. The development machine is running Windows XP SP2 as well and is a member of a domain. These steps are known to work with Visual Studio 2005 beta 1 (Whidbey) and will probably also work with Visual Studio 2003.

The first problem you might run into is not being able to see the workgroup machine from the Visual StudioàDebugàAttach to ProcessàBrowse… dialog. Doing the following will cause the non-domain machine to begin advertising itself as a workgroup machine to other networked machines, including your domain development machine.

1. System control panel, Computer Name tab, Network ID button. Told the "Network Identification Wizard" that this computer is part of a business network that does not use a domain.

The next thing your likely to run into is an error dialog after selecting the workgroup machine from the Attach to ProcessàBrowse… dialog. There are a number of things that can prevent the connection from being made and the error dialog may or may not point you in the right direction. Another thing to try that can help get things configured is to run the Remote Debugging Monitor on the workgroup machine manually. It has some good diagnostics that it displays at startup if there are connection issues.

2. Run Visual Studio Remote Debugging Monitor (msvsmon.exe) which you may find under Visual Studio->Tools. Install Remote Debugging Support from the Visual Studio installation CD if you can’t find it.

One way to satisfy the authentication requirements when debugging a workgroup machine from a domain machine is to create a local account on the domain machine that matches the account being used on the workgroup machine. You may also need to modify the local security policy on the workgroup machine to prevent all remote accesses from mapping to the guest account.

3. Run Administrative Tools, Local Security Policy and configured Local Policies->Security Options->Network access: Sharing and security model... from "Guest only" to "Classic". This keeps all remote access authentications from mapping to the guest account.
4. Created a local account on development (domain) machine to match local account on the workgroup machine (the machine being debugged). Add account to administrators group. Add access to the source tree to the account.
5. Run Visual Studio as the local account.
6. Open the project/solution.
7. Run the application on the workgroup machine.
8. Attach to the process from the domain machine: DebugàAttach to Process