I recently visited Nevada Regional Transportation Commission (RTC) to help them upgrade their Fiber Manager. It was quickly apparent that the folks there knew their fiber optics equipment well. The project team got to visit a test patch location where they had various devices, traffic light, camera, and configurations set up for testing. While discussing the setup, the question of how to model what they were loosely calling a “gator patch” came up anytime the conversation came around to Fiber Manager.


The gator patch is actually a pre-terminating patchpanel, used to connect the fiber optic network to control switches at an intersection. The switches in this scenario are not end points, so in Fiber Manager modeling them as the devices that they are would not meet their needs. To ensure a trace goes through these locations and shows a drop at each switch would require a jumper to be set up or an additional feature to be added to the model that is not physically there in the field.


After discussing the possibilities of creating custom features, custom tables, and custom model names, it was suggested that the gator patch could just be modeled as a standard patchpanel. A patchpanel with the subtype “intersection” or “instersectionSwitch” only requires a new subtype to be defined for patchpanel. Though the concept of defining backside ports on a device with all ports on one side was uncomfortable to the engineers, the decision was made to use this model.

The RTC also uses Wavepoint for various workers out in the field to view and trace the facilities. Since the RTC manages the fiber optic facilities for multiple entities, security (who should have access to what features and data) plays a big role in their Wavepoint implementation. Because the RTC has so many users of Wavepoint, they opted to configure it for use with Windows authentication. They also need to allow different access via different roles, and the person managing these roles requires a quick and easy way to add and drop people from these roles.

The proposed and accepted solution was to use an XML authentication store for each running instance of Wavepoint. Currently the RTC has two databases and an instance of Wavepoint for each. In the future they plan to have multiple fiber optic data sets for each entity and a Wavepoint instance for each data set. Each Wavepoint instance will have an XML authentication store located in its app data file to manage the users allowed to access that part of the RTC-managed fiber optic facilities.

Implementing an XML authentication store in the Wavepoint configuration is similar to implementing Windows authentication. In the web.config file, a connect string needs to be defined pointing to the URL of the authentication store.

<add name="FileBasedPolicyStore" connectionString="msxml://C:\Inetpub\wwwroot\Wavepoint\App_Data\TestAuthStore.xml"/>


Then that connection string needs to be defined as the connection string name of the “WavepointRoles” provider under the role manager.

<roleManager enabled="true"
         <add name="WavepointRoles"
              description="Wavepoint test authorization store"


This XML authentication store will give the RTC more flexibility and easier user management as they administer multiple Wavepoint instances across their network.