I really don’t get Verizon FIOS sometimes…

So here I am, once again, looking to upgrade FIOS service for my client and the one thing holding me back is Verizon itself. After a series of calls where I was simultaneously told static IP addresses would not change, would change and would not change, a technician who actually understands these things confirmed that yes, all 13 IP addresses would in fact change with the upgrade from the BPON ONT to the GPON ONT.

So once again, I’m on hold scratching my head as to why Verizon a) can’t change the name on an account without first deleting it (losing all IP assignments) and b) can’t seem to upgrade an ONT without throwing away the IP addresses associated with it and providing new ones.

One would think with the technology at our fingertips today, Verizon would have figured this one out.

To the developers of Visual Studio, common sense time…

While I don’t usually rant (yeah right) about developers on my blog I feel I have to on this occasion. Since yesterday, Visual Studio locked up while trying to load a project in that had, until then, loaded just fine. It was stalling at project 10/12 and initially drove me a little nuts thinking I had a corrupted extension, GhostDoc had gone nuts or node.js/Git had gone off the deep end.

Now, I know what your saying right now (let’s face it nobody reads this thing so I can say that) why didn’t you just look at the .SUO file and see what project 10 was and why it was failing to load. Well, I did. Turns out project 10/12 was a node.js link to a server that had been shutdown on my vmware server by flying spider monkeys.

All good right? Wrong. My rant is that Visual Studio in all of its glory simply stalled on 10/12, eventually faded to white and crashed. No error, no warning, nothing like “Hey, your project is pointing to ap4njs.uclnj.com and that server can’t be detected anymore..” which is what these days we should expect our software to be able to do.

I removed the entry from the .SUO file and now the project loads just fine.

Me: 1 – Visual Studio: 0

Testing Backups…

When the call comes in that there was an explosion in the building is not the time to ask “is all of our data backed up?” This just happened and reinforces my methodology of testing backups on a routine basis.

If you are backing up your data but not testing the backups by restoring data, volumes or virtual machines, then no, you cannot say you have a working backup. It’s the same as having batteries in the flashlight only to find a pool of acid in the handle when you open it after the lights have gone out from the batteries leaking.

Depending on your volume, at a minimum of once a month, you should restore from multiple points to test your backups. If your backup system supports multiple delta-points, pick the oldest you can find and restore those.

  • Restore entire virtual machines into your lab and fire them up to make sure they work.
  • Restore Exchange databases to your lab and make sure Exchange Server can mount them.
  • Restore SQL databases to make sure the account credentials were also stored so you don’t have to reassign logins.

In short, backup, backup, backup and then restore or don’t be surprised if you get a pool of acid in the flashlight handle when the lights go out.