:::: MENU ::::

Avaya IP Office 412 & 5610IP & Sonicwall VPN

Recently several new initiatives have caused us to look into extending our Phone system beyond the physical location of our main campus.  We have an Avaya IP Office 412 with 150+ digital extensions.  As part of the IPO you can do VOIP extensions but we haven’t had a large need to deploy those since our building was already wired for a phone and data network separately (Major PROS & CONS to this but not in this post). 

We do have however a couple handsets in locations where we can’t get a pair of copper for the digital phones so we have  a couple VOIP extensions on campus.  Those have worked great, plug the phone into the network, configure the IP and the VLan and your making calls.  So it should be that easy over our VPN right?  Wrong. 

After several hours of searching to figure out the issue we learned it was both a IPO Issue as well as a configuration issue in the Sonicwall Firewalls.  Since there was little documentation about this specific combo I have documented it here as well as the nuggets of info we learned along the way.

Hardware Used:
- IPOffice 412
- Avaya 5610sw IP-Handset
- Sonicwall TZ100 at remote location and Sonicwall EClass 5500 on main campus.


- Configure a new IP Extension on the IPO, Enter Only the Extension ID and Base Extension
- Configure the User for the Extension and Program Buttons Etc.
- Create an Incoming call route for the DID
- Connect the 5610 to the local network to make sure the phone is working locally. 
- Boot From DCHP, Enter IPO IP address (Phone Server) and Enter Voicemail Server IP (FIle Server)
- After the phone talks to the IPO it updates Firmware updates and the the phone is functional

At this point all was well and we were able to make and receive calls from the IP handset and it was time to take the phone to the remote site.  The remote site is where we started having connectivity issues and the phone wouldn’t boot completely.

-Plug in the phone and choose DHCP and it fails to connect to the server.  Do  a phone reset to clear out all networking gremlins from local network settings: Press Hold then 25327#
-Phone reboots and grabs DHCP address but cannot talk to the TFTP server.
Note: Workstation running the IPO Manager software runs a TFTP server when the application is open but not editing a config file.  If Manager isn’t running IP Phones will not update.

In the troubleshooting we could ping any device on the core network from the VPN except the IPO.  You could ping the Voicemail Server but no response from the IPO.  This was because the IPO requires you to  manually add an IP route for each subnet that is not the subnet of the IPO’s LAN1 Interface.

Some discussion forums noted that you would have to have a license for VPN or Remote IP Handsets but that is not the case.
To Configure the IP Route in the IPO:
- Open the IPO Config Manager and navigate in the tree to: IP Route
- Right Click and Choose New.
- In the new Route Config enter the IP Address of the Remote Router, IP Mask of the Remote Location
- The Gateway IP address should be the LOCAL IP of the Gateway on the Local network
  (Don’t enter the Gateway IP that you entered above in the IP Phone)
Choose the Destination of LAN1
- Save and Merge the Config. (Values shown have been modified and will not work with live config)

After this we should have seen the IP Handset boot, talk to the TFTP server and then work…. but that wasn’t the case.  When the phone would boot it would not show up as an extension in the IPO System Status nor would it check in with the TFTP server.  It would however appear to have booted and have a base extension without any call appearances.  Trying to use the phone resulted in a bunch of beeps.

After we were finally ready with the IPO configuration it now appeared something was blocking traffic over the VPN link from the remote location to the main campus. 

A call to Sonicwall reveled that in the latest firmware 5.5.x there are default settings enabled that should not be enabled to allow H.323 packets to travel from remote to local sites over VPN.  These settings should be enabled if you are NATing VOIP traffic via the WAN but not enabled if your VOIP traffic is traversing via VPN.
(Leads me to ask the question, can you not have a combination of VOIP Over VPN and VOIP via NAT, but that question can remain unanswered since it doesn’t impact us).
To disable these settings in the Sonicwall Admin interface go to VOIP and the ALL of the following should all be DISABLED on BOTH routers (Local and Remote).
- Enable Consistent NAT
- Enable SIP Transforms
- Enable H.323
It is important to note these setting changes require a reboot of both routers to take effect.

After a reboot of both routers and a reboot of the handset it registers with IPO as an extension and calls can be made and received.

It is important to note, this VOIP extension is not in the same physical location and it is the PBX operators responsibility to notify your dial tone provider of the physical location of that handset for E911 (PS/ALI Compliance).

Full Contact Baptism

A few weeks ago we had a big baptism service at Northwoods.  Since I am on the pastoral staff team I get to be part of the team that does the baptisms (in the lake in the summer, or this time THANKFULY inside!)  During our weekend services, over 115 people were baptized, it was a really cool weekend. 

I baptized several people in each of the services but one individual was most ‘memorable’. 

This particularly ‘memorable’ baptism made me think back to my practical ministry class in college where we all went to the pool and practiced dunking each of our classmates so we would know how to baptize people without falling over or leaving the person under the water etc.  But one thing they didn’t teach usin that class was to watch out for wild flying punches.

One of the guys I was baptizing who will remain nameless (to protect the not so innocent) was so excited when he came out of the water he jumped up with both fists in the air.  Well both fists were in the air AFTER one made contact squarely on my left eye.  After seeing a few stars, turned my back to the crowd not knowing what my face looked like and assured my wet friend everything was ok.  I was just happy I didn’t fall over knocked out cold.

I spent the next few hours wondering if I would wake up on Monday with a black eye as a Baptism weekend souvenir.  Luckily I didn’t have such a souvenir.

During the baptism services photographers were snapping shots to catch the exciting moments for each of those being baptized and they caught this action shot.

Black Eye Baptism

Church IT Roundtable Sponsors


The Spring 2010 Church IT RoundTable is just a month away.  If you haven’t registered go on over to www.citrt.org and claim your seat, QUICKLY!


One of the great aspects of the CITRT National events is to learn about great products and services that you might need to implement or use in the coming year.  We will be again having the Vendor Bazaar were CITRT partners can share, demo, explain etc the technology and tools they sell. 

Every time I attend a National RoundTable I end up learning a ton about a specific tech or product and then get home just in time to hear a staff members say,  “Would it be possible to… “

Maybe there is already one of those “would it be possible…” projects on your list and you don’t know of a vendor with the solution, shoot an email to info@citrt.org with your need and we’ll see if we can find a vendor to meet with you face to face at the Roundtable.

Maybe you know of a vendor that others should meet and learn what they have to offer, if you have a vendor in mind contact them and encourage them to check out the CITRT Spring RoundTable Sponsors Page or email info@citrt.org for more information.

Church IT RoundTable 2010



One of those can’t miss opportunities for Church IT people is about to take place just a few weeks away.  The Church IT Roundtable’s National Spring event will be hosted at Saddleback Church (Lake Forest, CA) March 11-12.

If you have attended a CITRT event in the past, you know what I am talking about.  If you haven’t attended I am serious when I say its a highlight of my year.  Every time I go to a CITRT event I learn tons about Church Information Technology, I meet awesome peers and I have a great time.  If you are in Church IT (staff, volunteer, vendor) you can’t afford not to attend this event. 


If you haven’t already, make plans to head to Southern California March 11-12.  For all the details check out www.citrt.org

Snow Day Adventure


Jonathan's first experience in the snow!Since today was a snow day, I thought I would break the silence here on the blog.  Well not exactly a snow day with no work or school… but Jonathan’s first day to play in the snow. 

Over the past few weeks Natalie has insisted to find a great buy and purchase snow pants for Jonathan incase of a big snow… Well she found the deal, and I hope Jonathan likes the pants because they are big enough for about 3 winters!

We found the deal just in time for an ‘amazing’ snow fall of 1.5 inches which warranted a snow day.  So Today after we finished lunch we all go our warm gear on (some more gear than others) and headed out to the snow.




Of course when you are out in your first snow adventure, you have to learn you can eat snow as long as it’s not yellow snow (or brown, thanks Toby).

Jonathan's first experience in the snow!

Jonathan's first experience in the snow!


Since the snow was really wet we decided to make a Snow Man… as soon as I started rolling the snow we could hear  “Ba, Ba Ba” (Jonathan’s word for Ball).  The bigger the snow ball, the faster and LOUDER we heard “Ba, Ba, Ba”.  Soon he was yelling “BA”.

Jonathan's first experience in the snow!


After rolling snow, we had our finished project and it was time for Dad to head back to the office, I think Jonathan enjoyed our lunch time adventure.

Jonathan's first experience in the snow!

Installing Printer Drivers on 2008 Server


In the process of migrating our servers from 2003 to 2008 and 2008 R2 we have started migrating our print server.  When you bring online the print server we downloaded the 32bit and 64bit drivers for each printer.  While most of our systems are still 32bit the new print server is a 64bit server, hence needing both drivers.

Installing the 64bit drivers was fairly straight forward but allowing 32bit machines to print via this server you also have to add the 32bit drivers as well.  In the past this has been the reverse but the process is the same.. Add and Share the printer then go back in to the Printer Properties and on the Sharing tab add the driver for the other, in our case adding the 32bit drivers for the guests.

When adding the 32bit drivers we ran into some issues.  Since a lot more printer drivers are shipping with windows in 2008 Server the wizard that adds the printer wants to install the OEM driver.  Which we found would print just fine from the server but give us one of two errors when we tried to add the 32bit driver.

The first 32bit driver error:


This error is a result from attempting to install a 32bit driver that doesn’t match the 64bit driver that the printer is currently using.  This is most likely caused by installing the printer with the OEM driver for that printer that came from windows update or shipped with Windows Server.  This is an issue because the Printer name in the OEM.inf and the .inf file provided by the vendor for the 32bit driver is somehow formatted differently … ie: ‘PCL_6’ might be ‘PCL6’ or some other slight variation in the printer name in the .inf file. 

The two solutions are to:

1. Find the oemsetup.inf file and edit the printer name or change the 64bit driver that the printer is using. 
2. The easier of the solutions is to change the 64bit driver from the OEM driver to a downloaded 64bit driver supplied from the vendor.  Once you change the driver or add the manufacture’s driver the install of the x86 driver will not be an issue.

The second 32bit Driver Error:



This occurs when the driver doesn’t match the formatting in the 64bit driver as above, but the issue isn’t resolved when using a vendor supplied 64bit driver.  You can attempt to find the differences between the two vendor supplied drivers as mentioned in issue 1 or take the following steps to install the 32bit driver.

1. Login as an Admin on any  client machine running 32-bit OS (it can be W2k3, XP, Vista doesn’t matter)
2. Access the print server PrintserverName and choose Printers and Faxes
3. Select the printer you would like to add the 32-bit driver
4. Go to properties
5. Sharing Tab
6. Additional drivers
7.Check the box for x86 for windows 2000,windows xp and windows 2003
8.click ok
9. The driver will be installed from the included drivers on the 32bit OS or it will prompt you for the location of the driver. 
8.Once the driver is installed you can check the server and the X86 box will be enabled.

Installing ACS Facility Scheduler on Remote Desktop Server 2008r2

Previously I documented the process for installing ACS’ Facility Scheduler Application on a 2003 Terminal Server as noted [Here].  But now its time to upgrade our ACS Remote Desktop Server to 2008r2 and the process for installing FS is a little different.  So here were our steps, your mileage may vary.

1. Download the latest installer from the ACS Client Portal. 
    (note the version released on 8/28/09 requires the .Net Framework 3.5)

2. .NET3.5 is included in 2008r2 but when you start the ACS FS installer you get the error displayed below. 

RemoteDesktop 2008r2


The next logical step would be to install .Net Framework, but remember it comes with Server2008r2, so you can’t just install it as the error below notes.  Rather you have to enable it not install.

RemoteDesktop 2008r2


The error notes to use the Roles Management tool, which you might think is Adding or Removing Roles, but what the error message really means is to go to the Server Manager then the Features item in the display tree then and then select add Feature to enable .Net 3.5.1. 
(Note: You can deselect the option to install WCF Activation which then won’t require you to install IIS on this server when you enable .Net 3.5.)



3.  After you have enabled .NET Framework 3.5.1 you can run the ACS Facility Scheduler installer.
4. Once the installer is complete launch the application and enter your site number
5. You may be prompted to download application updates, if prompted choose yes to update.
6. Once the updates are complete you should be able to login to FS with your login.
7. After updating and successfully launching the software you need to copy the application files to the default user’s folder so all users will be able to run the application on the Remote Desktop Server.  You can do this by the following steps:

  • Enable Hidden Folders by Clicking on Organize>Folder and Search Options> View Tab and then Select Show Hidden Files
  • Browse to C:Users%User%AppDataLoca
    • where %User% is the name of the account that was logged in when you installed FS
  • Copy the ‘ACS Technologies’ Folder
  • Paste the Copied ‘ACS Technologies’ Folder in C:UsersDefaultAppdataLocal
  • To place a shortcut on the Remote Desktop Server desktop for all users, go to c:Users%User%Desktop and Cut the ACS Facility Scheduler shortcut, and paste it in c:usersPublicPublic Desktop

8. Test your work by RDPing into the server (with an account that hasn’t logged into the server or the profile has been deleted) and you should be able to launch Facility Scheduler and access the application.

  • If ACS pushes out updates between the time you do the original install and the first time the user is logging in they may be prompted on the first use to update the application, if so choose yes and let the application update and then launch.


Happy Facility Scheduling…

Windows 2008R2 Remote Desktop Server Licensing – No more auto discovery

One of our recent projects has been preparing for and testing of the migration of our ACS Server.  We are are working to migrate our ACS Terminal Server from a 2003 Terminal server to a 2008r2 Remote Desktop Server and one of the problems that has caused frustration is the Remote Desktop Server CALs (Client Access Licenses).

We have software assurance so having those CALs wasn’t the issue, SA migrated our 2003 TS CALs to 2008r2 Remote Desktop CALs… The problems started when we brought the new server online and added the Remote Desktop Role it wouldn’t sync up with the license server. 

Previously we had setup one of our ‘backup’ domain controllers to be the terminal server license server so all Terminal servers would auto discover our Terminal Server licenses… but not with this new 2008r2 box.  Well alas I found out why… as noted here in the RD Licensing Tech net article:

“Prior to Windows Server 2008 R2, the license server was automatically discovered on the network. This discovery is no longer supported for an RD Session Host server that is running Windows Server 2008 R2.

In Remote Desktop Session Host Configuration in Windows Server 2008 R2, you must specify a license server for the RD Session Host server to use. You can either choose from a list of known license servers or manually enter the name.”

But nowhere in the document does it say how do setup said configuration… Other than you can do so by going to the Remote Desktop Session Host Configuration window.  In the RDSHC window (my abbreviation not Microsoft’s) you can see what license issues you have, and in our case we didn’t have an active license server but we couldn’t figure out how to fix that.

Finally today I came across this article [here] which links to this article [here] that actually gives the step by step instructions.  The gotcha is in the RDSHC window you need to not right click on any of the tree headings but select the top level and then go into the window and right click on the RD license server text for the properties menu to display. 

Incase the links go dark here are the step-by-step copied from the TechNet page.

To specify a license server for the RD Session Host server to use

  1. On the RD Session Host server, open Remote Desktop Session Host Configuration. To open Remote Desktop Session Host Configuration, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.

  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

  3. In the Edit settings area, under Licensing, double-click Remote Desktop license servers.

  4. On the Licensing tab of the Properties dialog box, click Add.

  5. In the Add License Server dialog box, select a license server from the list of known license servers, and then click Add. If the license server that you want to add is not listed, in the License server name or IP address box, type the name or IP address of the license server that you want to add, and then click Add.

    You can add more than one license server for the RD Session Host server to use. The RD Session Host server will contact the license servers in the order in which they appear in the Specified license servers box.

  6. Click OK to close the Add License Server dialog box, and then click OK to save your changes to the licensing settings.

You can also specify a license server for the RD Session Host server to use by applying the Use the specified Remote Desktop license servers Group Policy setting. This Group Policy setting is located in Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostLicensing and can be configured by using either the Local Group Policy Editor or the Group Policy Management Console (GPMC). Note that the Group Policy setting will take precedence over the license servers configured in Remote Desktop Session Host Configuration.

Now.. I have to say I am not complaining that the new navigation is bad.. just the new way things are being displayed in 2008 and 2008r2 one has to get accustomed to… BUT i am complaining that its a little frustrating when you search the net for ‘how to configure type articles’ and you have go to three or four layers deep to find the instructions.

So… i hope this helps you in you quest to configure the Remote Desktop license server… as well as provides me a place to look when I forget next time I bring online a new server.

Clean-up of a Orphaned Active Directory Server 2003R2 Namespace

In my previous post [here] I documented how to enable Access Based Enumeration on a 2003R2 DFS AD Namespace.  Since then several times in testing and now once in production or NameSpace has become orphaned from its NameSpace Server Host and I have had search how to clean-up an orphaned DFS Namspace.

Incase it every happens again… and so that I don’t have to search the web and try to figure out which random terms I used in the Google search I am documenting the process to fix an Orphaned Namespace here… for your use as well as mine. 

Since historically just pasting the links ends up burning me… I have included the step by step procedure, that was of course copied from several websites (Note: I am not claiming, any responsibility for, or noting the existence of, original content).

Your Mileage may very and no implied guarantees that the following steps will solve your issue… But the following did fix my issue with an Orphaned Namespace.

These steps have worked to delete the orphaned namespace because of server failure or loss of DFSRoots directory
(or migrating from one SAN to another and thinking that DFS replication will replicate your DFSRoots to a new volume on the new SAN… which by the way DFS replication doesn’t replicate DFSRoots)


The domain-based DFS configuration is stored in the AD database as well as some settings on the DFS Namespace Host server, so every time you launch the DFS management console, it will try to retrieve the DFS information from AD.

There are two nodes in AD which store the information of the DFS Namespace:

Node1. Store the DFS Namespace information which shows under the Namespaces node in DFS management console. CN=DFS-Configuration, CN=System, DC=Domainname, DC=domainsuffix

Node2. Store the DFS Replication group information which shows under the Replication node in DFS management console. CN=DFSR-GlobalSettings, CN= System, DC=Domainname, DC=domainsuffix

ON a DC use ADSIedit.msc to delete the orphaned namespace information domain.tldDFS_Namespace under the node CN=DFS-Configuration.

1. Launch ADSIedit.msc

2. Connect to "Default naming context" (the domain partition)

3. Expand and locate to the following node:
CN=Dfs-Configuration, CN=System, DC=ourdomain, DC=tld

4. Check if the orphaned namespace CN=DFS_Test is under it, if so, you may delete this node CN=DFS_Test

5. Afterwards, please run "repadmin /syncall" if there are multiple domain controllers in the environment

6. Then run "dfsrdiag pollad" on all the DFS member servers to manually make them sync the information from AD database.

Then, you may launch the DFS management console and then right-click on the orphaned namespace, and then select Remove Namespace from Display… if needed.

After these steps you can proceed to re-create your DFS Namespace. When creating the Namespace you may receive the error: “ The Server you specified already hosts a namespace with this name. Please Select Another Namespace or another server to host the namespace.”

If that occurs:

1. Stop the DFS service by tying net stop dfs at a command prompt.

2. Delete the following three registry keys/values:

3. Reboot the server and restart DFS Service.

4. If it still appears, delete the Namespace from the Display.

5. Proceed to recreate a Namespace.

ACS (ChMS) and PCO integration … Dead for now

As I have discussed in previous posts  [1] , [2] and [3] we would love for synchronization or sharing of data between our ChMS and Planning Center Online.  My recent push has been to get the sync to work for ACS and PCO, obviously because that would impact us most because we use ACS. 

In our conversations with PCO Owner Jeff Berg we found out that PCO had plans to synchronize with multiple ChMS products not just ACS, which was great.  In that conversation multiple staff from ACS talked thru how to make the APIs work and for PCO to integrate. It looked like we finally had progress to an integrated solution not just for ACS but all Church Management systems.

Then turn the page a couple months later, and this week I was disappointed to receive the email below, which I totally can understand but disappointed none the less.

Hey Jason,

I just wanted to let you know that we have decided to kill our "SharpSync" project for now. We have been working on it for over a year and just have not seen any fruit from it. The complexities of working with different schemas & APIs are too big of a hurdle for our small team to attack…


We have had a long discussion this morning about integration and the difficulties in what we were trying to accomplish. We have found this too large of a task for us to accomplish.  This is not just with ACS but with all of the other ChMSs we were talking to. We have spent over a year and a lot of cash doing this and just haven’t found a reliable way to integrate with all of the ChMS systems out there.  Every time we thought we were clear we would run into a hurdle with an API or data consistency issue.

We have discussed this with some other ChMSs and some have decided to integrate from their end…

I’m really sorry for this, I was very excited for this project but it just didn’t work.



So if you who have asked about such a tool, I encourage you to contact your ChMS and see if there is a way to make this project work.  If you are an ACS customer contact Sally Grantham and let her know your needs and interests.

I will stay to the PCO crew, thanks for the effort, and I still hope that we can see this product work.