cabling and pinouts

One of the important aspects of a Vocera project that should not be overlooked in the planning phase is the cabling requirements. Different parts of the system have different requirements, likely you will need a few different cables to get your system running. Here is what we will cover today:

1) Basic Cabling
2) Ethernet Crossover
3) T1 Crossover
4) Analog

Special notes
*** I suggest you buy quality cables and put a cable tester on them prior to use.

*** You should ask your data center staff if they will provide required cables or give you their cable color requirements if they have been defined.

*** T1/PRI section assume you are NOT using CSU/DSU's.


Basic Cabling
Assuming someone reading this knows nothing about cabling we are going to start off simple. Every time you connect a PC or server to a switch you will use a normal straight through cable, sometimes called a patch cable. Both ends of this cable will terminate in the same sequence, probably like this:

It's a little blurry, but with the gold pins facing up you should see the following colors:
1 - White/Orange
2 - Orange
3 - White/Green
4 - Blue
5 - White/Blue
6 - Green
7 - White/Brown
8 - Brown

Here is a butchered cable, destroyed for your entertainment:

OK, so our straight through cable will have these same pinouts on BOTH ends! The next two cables will have these pinouts on ONE end. This means you MUST check both ends of a cable to know if it's really straight through.

For review this will be the cable type used to connect VS, VTS, and VRS server's NIC cards to their switchports.


Ethernet Crossover
The second cable we might need is an Ethernet Crossover Cable to connect our BCWS to it's AP. I say "might" because some PC's and some AP's will detect the need for a crossover cable and automatically reconfigure itself to use a straight cable as if it were a crossover. Strangely it's actually the higher end gear that assumes you will buy or cut a crossover if you need one. Because these cables do play havoc in networks by people using them where they shouldn't, I strongly suggest using a red cable for Ethernet Crossover Cables. Assuming we need one of these and didn't buy one, here is the pinouts:1 - White/Green
2 - Green
3 - White/Orange
4 - Blue
5 - White/Blue
6 - Orange
7 - White/Brown
8 - Brown

A little logic tells us that Ethernet must be using pins 1,2,3, and 6 because that is the only pair changes at one end of the crossover. OK, out of the minor leagues now. The VTS will need some special connectors for it's Dialogic card.


T1 Crossover
If you are doing T1 or PRI digital integration, you will need a T1 Crossover Cable. T1's use pins 1,2,4, and 5 so if we try to use a Ethernet Cable or a Ethernet Crossover Cable to connect our PBX to our VTS we will not be able to get our link up! Again I choose a color for this cable that makes it completely different than anything else in the data center. Lets take a peak at these pinouts:
1 - Blue
2 - White/Blue
3 - White/Green
4 - White/Orange
5 - Orange
6 - Green
7 - White/Brown
8 - Brown

If you need a "loopback plug" to test for the carrier or your PBX vendor you can simply take two pieces of wire and use one from pin 1 to pin 4 and the other from pin 2 to pin 5 crimped in the same RJ45 connector to do the job. Actually I will borrow this from Google images, thanks somebody for not making me get the camera back out.

Analog
The last bit of cabling we probably can't buy our way out of, analog integration throws us a few gotchas that need to be planned for. First off lets take a peak at our supported 12 port Dialogic card for a moment:Hmmm, only six ports for 12 phone lines.... Dialogic decided to use two lines per port. An "RJ11" jack has 6 pin positions, normally for phones only the center most pair is used, but for this application we must use 4 pins per jack, thus two lines per port. Here is how we do this.

Normally when I show up I have a run of cable coming from the PBX to the VTS server location terminated this way:
This is actually good because we can plug in a test set to each plug and test the line by calling a desk phone, we can also test our Class Of Service and make sure LD is setup and we know about any LD codes that might have been missed in discovery. Once we are done with our testing and we checked the extension numbers we have to cut these all off.

If Orange is x1001, Green is x1002, Blue is x1003, and Brown is x1004 I would want to crimp them down this way to keep logical.Now I plug Orange/Green plug into port 1, and Blue/Brown plug into port 2 and I should have four working lines, but do I? I have seen this get messed up, so now I will dial 1001, 1002, 1003, and 1004 to make sure each of them gets me "Please say the name of the person or group you would like to speak to." If one of them fails I know right where to go to look for the issue.

The very last step in analog integration is to test the hunt group. Depending on the PBX their will either be a "roll down" from 1001->1002->1003->1004 or a "hunt pilot" of 1000 with each of the four numbers assigned to it. In the first case dial 1001 four times and you should get Genie four times, or in the later case dial 1000 four times and look for the same result.


Conclusion
A few basic links to get you by:
STRAIGHT THROUGH CABLE for all servers <-> switchports
ETHERNET CROSSOVER CABLE for BCWS <-> AP
T1 CROSSOVER CABLE for VTS <-> T1 PBX port
BUT SET for testing analog lines
CHEAP CRIMP TOOL just incase you don't have any
BASIC CABLE TESTER to be sure your pins are right

You may also need a punch down tool or a tool for toning out drops, as well as an assortment of RJ11's, RJ45's, and some Cat5 cable but most places have those things laying around somewhere already, as long as you know where to look and who to ask.

Badge Configuration Workstation

So lets just pretend we have a Vocera implementation coming up, we know we are getting a bunch of badges and we have our servers ready for installation. One piece that gets missed from time to time is the Badge Configuration Workstation, or BCWS. Here is why we need one and how to set one up.

When new badges arrive from Vocera, or an old badge is reset to factory defaults, it will boot up with the following information:

• The only SSID the badge will look for is "vocera"
• The badge will TAKE an IP of 10.X.X.X with or without DHCP present
  
• It will look for a Vocera Server at 10.0.0.1
• It will load firmware from that IP if offered and a copy of badge.properties
  

If our production SSID is "supersecrethiddenssid" and our VS is on an IP of 192.168.1.1 it's safe to say a factory badge will never find it.

Vocera's answer to this situation is a BCWS. The idea is this:

• Configure a thick AP with SSID = vocera
• Connect that AP via Ethernet crossover to a PC with an IP of 10.0.0.1
  
• On that PC run the badge configuration portion of VS
• Load the production data values into the Badge Properties Editor

Simple enough. In the real world I see three approaches frequently:

1. Old PC and a thick AP setup for the task
2. Admin's laptop and mini AP configured when needed
3. Overkill over-engineering

The most common approach is to grab an old desktop PC from a junk pile and a thick AP that was pulled out during LWAPP conversion, cut a crossover cable and load it up. If we go this route I suggest the following:

1. Install a fresh copy of XP Professional SP2 on the PC
2. Set the NIC to 10.0.0.1 with a subnet mask of 255.0.0.0
3. You can leave the default gateway blank
4. Disable Windows Firewall
5. Connect a Ethernet crossover cable between the workstation and the AP
6. Setup AP with ssid "vocera" completely open
7. Insert the Vocera Server media and run the installer with only Badge Utilities selected (unselect Vocera Server) and take all defaults
8. I recommend turning the antenna power down to the lowest level possible
   

A few things on the PC itself. The official Vocera media is DVD, make sure the PC has a DVD-ROM. If it has CD-ROM or no optical drive you can load via USB, make sure it has USB ports and drivers if needed. I've seen lots of old PC's used for this, it's amazing to me how many times that neither of these requirements are met.

Once you have XP running on the PC you can connect it via the CROSSOVER CABLE (I like red for crossover cables) to the AP. If you need an AP and you like Cisco, you can get one of these ACCESS POINTS and put this configuration on it:

*** BEGIN CONFIG

enable
Cisco
conf t
int bvi1
ip add 10.0.0.2 255.0.0.0
exit
int dot11radio 0
ssid vocera
authenticaion open
no shut
exit
exit
wri mem
reload
yes
*** END CONFIG

In a minute or two you the AP will be online and ready for connections.

So for a half time review, we have a fresh install of XP on a PC and a crossover Ethernet cable connecting it to a AP serving the SSID of "vocera" and a pile of badges to flash.

Before we can actually flash them, lets create our badge.properties file. On the PC go to: Start->Programs->Vocera->Badge Utilities->Badge Properties Editor

You will see a DOS kicker then a GUI. You will need to choose your badge type, B1000 or B2000, and put in all production settings. Be very careful to make sure this accurately represents your production wireless and Vocera settings. When you are done save and exit the Badge Properties Editior.

Now: Start->Programs->Vocera->Badge Utilities->Badge Configuration Utility

You will see the command window open and load the settings, scroll up and check them (encryption keys will be encrypted.) If it looks good, slap the battery in the badge and watch it scroll by. If your VS settings are correct, the badge should settle on a display of "Logged Out" and connected to the active VS if you check the menu on the badge.

All of this assumed a dedicated PC and AP for the role of BCWS. Another option I mentioned was using the sys admin's laptop and mini AP. If you go this route do the following:

1. Set NIC to 10.0.0.1 with a subnet mask of 255.0.0.0
2. Disable any firewall running
3. Install Badge Utilities off the Vocera Server DVD
4. Connect to AP via crossover (if you need an AP look HERE)
5. Follow remain directions above

The only trick is remembering to set your IP before flashing badges.

I suggest you stick with option #1 for most environments, or sometimes option #2 is a little better for people who with many sites on a campus to support AND who go everywhere with laptop in hand.

The final option I mentioned is all the trickery that sharp people put into their own networks. This is outside of the scope of what I support for clients, and I may be mistaken but I don't think Vocera Support would be quick to jump into problems of this nature so I will skip it entirely for this post.

If you have comments or questions about the role of the BCWS please post them below!

Dialogic cards

This is one risk item that can be carefully planned for and still messed up, so I think it would be a good subject to cover.

There are just a few tricks to getting a Vocera Telephony Server put together right on the first try, but there are often problems. Here is what we need to do:

1) Get the right server
2) Get the right riser
3) Get the right card
4) Setup the card correctly
5) Load the right driver

The trick to meeting schedules and budgets is doing them all right the FIRST time!


Get the right server
Looking up the server requirements for the VTS shows it's not a power hungry box. Take a look at the last page of this DOCUMENT.

Ah but the catch is that little note about checking www.dialogic.com that's where you find out that a Dialogic card is almost a foot long and wont fit in many server chassis. Why take a look at an analog board next to a Dell 1950:


Crappy photo, I know, but notice how both risers are only half as long as needed for this card! I will eventually leak out all of my biases on this blog and I will start now: I love HP and a DL380 is a great chassis. Just take a look at THIS SERVER.


Get the right riser
Once we have a server that will hold the card, we need to make sure we have the correct slot time for the card to go into. Here is where the question comes up... I dread this.

First off, go educate yourself: http://en.wikipedia.org/wiki/PCI_Local_Bus

The most important part boils down to this "... Later revisions of PCI added new features and performance improvements, including a 66 MHz 3.3 V standard and 133 MHz PCI-X, and the adaptation of PCI signaling to other form factors. Both PCI-X 1.0b and PCI-X 2.0 are backward compatible with some PCI standards. With the introduction of the serial PCI Express standard in 2004, motherboard manufacturers have included progressively fewer PCI expansion slots in favor of the new standard."

OK so current servers ship with PCI-E slots, and prior to 4.1 Vocera only supported a PCI versions of Dialogic cards that could be used in a PCI or PCI-X slots. I am going to get personal again, I like the old PCI cards because they have a long history of working well for Vocera. All I need to do is ADD THIS RISER to my DL380 and my server is ready to go!


Get the right Dialogic card
If we have made it this far we are bound for success! This question is an easy one, analog or digital?

If we need analog/copper lines to integrate to our PBX we need the ANALOG CARD.

But I hope everyone is going the digital route, if you go basic T1 or ISDN PRI you will need the DIGITAL CARD.

Either way it's that simple if you picked the PCI/PCI-X style of riser card.


Setup the card correctly
Basically this part is for your partner to configure, there is one thing that should be done to the card before it goes into the server.


Load the right driver
The first time Windows boots up after this card is inserted a little wizard will pop up and offer to ruin your life, just cancel out of it. It is CRITICAL that you let your partner install the correct driver, getting the wrong driver out of the system is far harder than it should be.


Conclusion
I will go over analog pinouts and some aspects particular to ISDN PRI and integrations sometime in the near future, but I need to get home to a good macro lens so I can get a few good close ups of the wires and connectors.

dirty little backup via batch file

I am always asked how to get a copy of backups off of the Vocera Server because backup solutions aren't part of their Vocera project. There are a million ways to skin this cat but I am going to start with the very simplest way I can think of to get a copy off to another Windows server. I may come back and detail some more advanced ways in the future, but in this case I will backup two days worth of data to my VRS from two Vocera Servers.

1) In VRS I will create two folders to share.
D:\VoceraServer01
D:\VoceraServer02

2) I map a persistent drive on each VS to it's respective folder, in my case I will do my active VS using the B drive (for Backup right?)
B:
\\VoceraReportServer\VoceraServer01
check "Reconnect at logon"
Use different username and pass if required

3) Now I need a local staging directory on my Vocera Servers, make it easy on yourself and keep the path the same on each cluster server. I will also use this to store other important things like my license key. I will make this folder ABOVE the vocera directory. Lets take off the training wheels and go to the command prompt.
"mkdir C:\ThomsBackupHack"
"cd C:\ThomsBackupHack"

4) Next we need to create a batch file to do our dirty work.
"edit BackupHack.bat"
"ALT + f" will open the File menu
"s" will save the file as C:\ThomsBackupHack\BackupHack.bat
"ALT + f" will reopen the File menu
"x" will exit the edit mode

5) Now we just need to put in the logic for what we want to do.
# This is not Thom's fault, I did this on my own :)
# Make directory to stage files in
mkdir C:\ThomsBackupHack\TEMP
# Get backups, they are the .zip files
copy C:\vocera\backup\*.zip C:\ThomsBackupHack\TEMP
# Get a copy of the badge.properties
copy C:\vocera\config\badge.properties C:\ThomsBackupHack\TEMP
# May as well grab the server properties file too
copy C:\vocera\server\Properties.txt C:\ThomsBackupHack\TEMP
# I usually put a copy of the license files in the root of c: so I grabbed that too
copy C:\mylicense.txt C:\ThomsBackupHack\TEMP
# Now that our files are together, lets cleanup our VRS directory
rmdir /S /Q B:\YesterdaysBackup
# Then we can take the folder named TodaysBackup and make it YesterdaysBackup since it's now a day old
move B:\TodaysBackup B:\YesterdaysBackup
# We should now have a clean directory for todays data
mkdir B:\TodaysBackup
# Now we can sync our staging dir on the Vocera Server to the VRS
copy C:\ThomsBackupHack\TEMP\*.* B:\TodaysBackup
# When we are done with TEMP we should clean it up
rmdir /S /Q C:\ThomsBackupHack\TEMP
# This should conclude our little backup batch file.

To be precise, my file looks like this:
mkdir C:\ThomsBackupHack\TEMP
copy C:\vocera\backup\*.zip C:\ThomsBackupHack\TEMP
copy C:\vocera\config\badge.properties C:\ThomsBackupHack\TEMP
copy C:\vocera\server\Properties.txt C:\ThomsBackupHack\TEMP
copy C:\mylicense.txt C:\ThomsBackupHack\TEMP
rmdir /S /Q B:\YesterdaysBackup
move B:\TodaysBackup B:\YesterdaysBackup
mkdir B:\TodaysBackup
copy C:\ThomsBackupHack\TEMP\*.* B:\TodaysBackup
rmdir /S /Q C:\ThomsBackupHack\TEMP

• Now if we double click BackupHack.bat we should see a file named "TodaysBackup" in the C:\VoceraServer01 directory on the VRS.
• If we double click it again we should now see a file named "YesterdaysBackup" in the same directory.
• If we run a manual backup from the admin console then lauch the batch file again we should notice a new .zip in the TodaysBackup folder.
  

Pretty slick huh?

Now all we have to do is schedule it for just after our nightly backup runs. Mine is set to run at 2:00 am so I will return to the command line one more time:
"at 03:00 /every:M,T,W,Th,F C:\ThomsBackupHack\BackupHack.bat"

If you want to check the scheduler just type "at" at the command line for a list of scheduled jobs.

Once VoceraServer01 is done and working, you will need to duplicate on the rest of your cluster servers to be sure you are backing up the active server.

The one file I can't test backups for is telproperties.txt but combining this logic with google should get you what you need. UPDATE: that would be C:\vocera\dialogic\telproperties.txt

I should probably mention again, you should really be using an enterprise backup suite for your servers, especially mission critical ones, but this is a first level of safety net.

fixing IE pop up size for the admin console

I met a guy in Cupertino when 4.0 came out, and just bumped into him again at a 4.1 event in San Jose. While we were poking around the admin console on a VS he showed me where to allow Vocera to control the size of the pop ups so you can see helpful buttons like "Save" or "Save and Continue" without scrolling.

My test box is a fresh install XP Pro sp2 with IE 6.0 (VS 4.0 is running on box) and you can see we have the issue by default:

- Open Internet Explorer, click Tools, and Internet Options.

- Go to the Security tab, highlight Internet, click Custom Level

- Find the parameter "Allow script initiated windows without size or position constraints" and choose Enable.

- OK, Yes, OK, then close the browser.

Next time you open up the Admin Console the pop up windows should open at the size Vocera wants to give you instead of what MS thinks you should get.

I need a place to put some general public info

I have a collection of links, part numbers, and little tricks but I wanted to put them someplace where other people could use them and add comments/tricks of their own so this seemed like the best format for it.

Just before I open this up to the world:
1) No "partner only" information posting.
2) Do not post anything that breaks a NDA.
I will remove any posts questionable.