Access to ward and branch network equipment

I was recently called to be the stake technology specialist. I have a 20+ Years of IT and Telecom background experience and hold numerous technical certifications in addition to Bachelors and Masters Degree. While supporting my stake I am finding that there are issues beyond a phone call that will resolve the networking issues and I would like to request the ability to have remote access into the various wards networking equipment so I can reboot access points or adjust transmit power settings in addition to locating access points to improve coverage and whatever I can do to improve the wards and branches overall networking experience. We have very problematic issues that some things can be resolved but will,work with the FM group to upgrade or replace equipment as needed. I am open to options and whatever I can do to resolve issues quickly. Please keep in mind that I have a full time job and can on,y work on these issues after hours.

Here is a great starting point and resource to help you as a new STS https://www.lds.org/help/support/meetin ... y?lang=eng I found it very helpful when I was an STS

The church uses a very small staff. Survival means keeping to a standard configuration. You can inquire with support, but I suspect short of becoming a church employee, you're not going to get any access beyond what's available in tm.lds.org, which is pretty limited.

What you can check is to make sure your install is up to date. Typically, that would be a MX64 firewall and MR33 Access Points. If you've got older APs (like a Cisco 1040), and APs that do not show up in TM, then I'd work with FM to get your equipment updated. You may also want discuss adding or relocating APs as needed for better coverage.

Note that FM has to work within their budget, so it's better to talk to them sooner than later so they can put it in their budget for next year.

I totally hear ya on this one. I was an STS in Missouri before moving to Utah, and because there is no economy of scale out there the STS was much more involved, out here in Utah my FM hires a contractor to do everything (we pay money[tithing money] to people rather than using the volunteer efforts of people called to do the same thing - often with higher skill sets). The differences from place to place are very difficult, add to that the different and almost unique approaches that FM's have, burdened by any kind of HC that thinks they need to be involved as well.

Get this... we have a new building, it has a satellite receiver, so I was going about setting it up on the network - in the Facilities zone for whatever hair-brained architecture goofiness decision that was (we manage the Meraki from the User zone, why manage the satellite receiver in the FAC zone). So I thought, hey, I have 4 ports on the back of the Meraki, 2 are reserved by default as the USER zone, the 3rd is reserved for the FHC zone, and the 4th is reserved for the FAC zone... since I only needed 2 ports (I'll never have an FHC in this building), I called the GSC to see if we could move port 3 to the FAC zone so I could plug in the satellite... nope, sorry... out of standard, can't do it.... don't mention that in the same call the 3rd port was already in the user zone (not standard) but hey, diddle, diddle, now I get to buy a switch, use 3 cables instead of 2, find a spot for another power block. and all this AFTER the system was installed by professionals being paid anyway and they didn't set it up. OH, and I had to go back in and get everything working in TM anyway, it was all setup and associated with the FM office or whatever because the building wasn't in the system at the time. I'm responsible to get all the grunt stuff going, but the fun stuff to offset the grunt stuff goes to someone else.

I honestly don't understand it. My FM has sent service guys in to 'reboot' an AP, a service call that cost money rather than give me a key to the attic. oh, and hey, our router lost power last friday, right before the big Stake Super-Saturday activity. IF I hadn' been messing around with the receiver in TM I'd have never known, that activity would've had issues, I'd have been called to do something in an emergency rather than planned, etc... a simple notification is too much to ask if something goes down?

And that's all before we get into tuning anything. I've had pretty good luck just asking the FM to put the AP's in the hallway ceiling rather than the attic...

Basically, it comes down to what's been said before, the standard exists so we can do more with less(people) - and being in a remote hosting enterprise data center architecture group, I get that totally... it is often more expensive to make all those things available to you than if you just convinced your FM to add a couple more AP's to ensure coverage rather than trying to tune radios, and protocols, etc...

my two cents.

johnshaw wrote:so I was going about setting it up on the network - in the Facilities zone for whatever hair-brained architecture goofiness decision that was (we manage the Meraki from the User zone, why manage the satellite receiver in the FAC zone).

Actually, I think there's sound technical reasons why that is.

The firewall and APs contact the Cisco Meraki cloud. TM controls it by talking to that cloud. So, it can be controlled by any web browser that has an internet connection. The APs of course are connected to the User zone since that's where you want the wireless users to be connected.

The satellite receivers are a different story. They're just dumb devices that wait for something to connect to it. As such, putting them on the locally NATed 192.168.x.x isn't going to work. TM has to reach though the church network to contact them. So, they have to be on the global 10.x.x.x network. While it might work to put them on the SP (FHC) zone, there's a small risk that unauthorized users might be able to disrupt them. Plus, all buildings have a FAC zone. Not all have the SP zone.

I don't know as the receivers are capable of initiating a responsive connection to TM. So, while it may not be ideal, it seems like a reasonable implementation of Cisco's design to meet the church's needs. Or am I missing something? I know you know networks, so I'm not getting why you think it's strange.

in the old stake center I had to have a cable run from the attic to the library because only one user cable went from the attic to the satellite closet. I have a switch there for the teradek, plus the printer. But required another cable, a contractor to run it, another switch to hook it up, etc...

All the FAC zone does is cost more money to setup the satellite receiver on the network. If it was on the user zone, it's the cost of a single cable.

But how would TM be able to contact a locally NATed address from SLC?

While the Help Center discourages managed switches, it might be an option in this case. I notice that TM does seem to have some kind of tool for dealing with switches. So it must have some level of approval.

johnshaw wrote:in the old stake center I had to have a cable run from the attic to the library because only one user cable went from the attic to the satellite closet. I have a switch there for the teradek, plus the printer. But required another cable, a contractor to run it, another switch to hook it up, etc...

All the FAC zone does is cost more money to setup the satellite receiver on the network. If it was on the user zone, it's the cost of a single cable.

My satellite receiver isn't connected to any zone. If the church wishes it connected, they are welcome to pull the additional cable and install any additional hardware.

russellhltn wrote:The satellite receivers are a different story. They're just dumb devices that wait for something to connect to it. As such, putting them on the locally NATed 192.168.x.x isn't going to work. TM has to reach though the church network to contact them. So, they have to be on the global 10.x.x.x network.

It's my understanding that authorization for receiving special broadcasts, such as, regional conferences, temple dedications, etc., is done over-the-air via the satellite signal. It's a one-way transmission without confirmation if any particular receiver actually got the authorization. (I'm sure it's sent more than once.) With the receivers in the FAC zone, each would have a unique Class-A 10.x.x.x IP address that could be accessed via VPN directly from CHQ. Obviously, a 2-way communication with each satellite box could easily include an acknowledgement that they actually heard and understood the message. This would most likely reduce the number of frantic phone calls they get prior to each selective broadcast. I would imagine the security of the individual authorization keys could be maintained better over a VPN than broadcast via satellite as well, but that's just an assumption on my part.

It's not necessary to connect the satellite receiver, but there are a few benefits. You can go into TM and check the receive levels from anywhere. I'm sure the receive levels are visible to certain others as well. I'm waiting to see if the low signal strength will trigger corrective action from FM.

You can also change the audio program from TM.

Low signal strength triggers a message that tells you to contact the GSC. They then have a decision tree that you need to be at the stake center to go through with them.