Well, we have had a number of fun things going on around here. This is a rundown...
- Single wireless experience for both campuses
- Single point of management and administration for wireless infrastructure
- Better network security utilizing VLANs and router ACLs to allow and restrict traffic accordingly
- Single platform, with robust service and support available
- Forced upgrades to infrastructure on Mesa campus, improving our network
- Mesa wireless clients get network settings from Gilbert campus
- All Mesa wireless traffic now has to make a round-trip over our T1 link between the campuses
This last point didn't really hit me until we actually began testing and I noticed that my laptop had a 10.100.x.x IP address, which is in the Gilbert campus address space. While I initially got very uneasy about this, a couple of things have eased my fears. First, after some testing, network performance wasn't that bad. Web browsing was fine and LAN access, while slower, was tolerable. Second... well the second point brings me to my second point! :-)
2. As my boss recently blogged about, we have just signed up for an Optical Ethernet connection between our campuses. We will have a 200Mb pipe linking our Gilbert and Mesa campuses. Any issues we may have with our current wireless implementation (related to our WAN link) will soon be gone. Also, we are looking at getting a second Controller for our Mesa campus at some point. This would be set up in a 'client' role, keeping the Gilbert Controller in a 'server' role. So, we would still only have one place for management, but each campus would have a local controller for their respective APs, handing out network settings each for its own campus. This would keep local traffic local... a good thing!
Also, this high-speed link will open up conversations about file syncing, remote backup, VoIP integration, and more. Fun Stuff!
3. Austin Spooner (here, then here, I believe) was kind enough to inform us (via Nick) that Firefox 3 didn't seem to like our SSL implementation. After testing and confirming the problem, I made a call to Network Solutions. We bought our cert some time ago and have not had any problems until this time.
As it turns out, when I set our certificate up, I only installed our certificate. I was supposed to get a total of four certs from NS and put them all on our web server. Since I did not do that, Firefox 3 correctly reported it could not determine the provenance of our certificate.
I was quickly directed to our Cert Management site and downloaded the other three certs I needed. One was installed as a root cert and two were installed as intermediate certs. Once I restarted the WWW service on our web server, things were right as rain.
It's amazing how things work when you do them correctly! :-) Thanks again, Austin!
4. This one ties in to number 1 above. Our new wireless implementation required us to make some not-insignificant changes to some of our check-in kiosks. Actually, the solution we landed on required us to make changes to all of our kiosks (on both campuses). You see, some of our kiosks are out in the middle of a space, so they require wireless access to the network. Well, with the new wireless solution, these kiosks had to be reconfigured. And, like a snowball rolling down hill, this thing got bigger and bigger, faster and faster, and it almost wiped us out. But, we landed on a solution that, I think, will work pretty well and will be an improvement over what we had previously.
When we changed the wireless network settings, we broke everything. The kiosks - ELO touch-screens - had a program loaded and provided and on-screen keyboard and auto-logon capability. The problem was that our wireless network requires authentication (against AD) before allowing you on the LAN-access VLAN. The ELO app, however, did not use cached credentials, so it was not able to log on! There was no network available for the AD authentication. A great catch-22, but very frustrating... we needed the network to authenticate, but the network itself required authentication!
So, we decided to remove the ELO software tool and look for other ways to auto-logon. We soon found many articles describing how to do this. A few registry key changes later, and we had our computers logging on automatically. Of course, we weren't done yet. Now, the computers were using cached credentials (because the wireless network wasn't up yet) and the GPO has these machine automatically start IE in kiosk mode and open our ckeckin app webpage. Well, with networking still down, the computer were just showing a 'page not found' error. Not very helpful.
Our next step, then, was to figure out how to tell these computers to wait until their network was up before starting IE and the checkin app. After a bit of fiddling around, I landed on this VBScript:
Set objShell = WScript.CreateObject("WScript.Shell") strCommand = "ping -n 1 SERVERNAME" strResults="" while not InStr(1,StrResults,"Reply from")>0 WScript.Sleep 5000 Set objExecObject = objShell.Exec(strCommand) Do While Not objExecObject.StdOut.AtEndOfStream strResults = objExecObject.StdOut.ReadAll() Loop wend objShell.Run """C:\Program Files\Internet Explorer\iexplore.exe"" -k http://SERVERNAME/CheckIn/scancode.aspx"
All it does is try to ping a server and waits until it gets a reply before executing our ckeckin app. We just changed the GPO to run this script, rather than IE itself. Simple, but effective. So, our config change steps are:
- Remove ELO tool
- Modify registry for auto-logon
- Copy VBScript file to kiosk computer
- Reconfigured wireless to point to new infrastructure
The one realization we had late in the game was that this change affected all kiosks, not just wireless ones. Since we changed the GPO to run the VBScript file rather than IE directly, we had to put the VBScript file on our wired kiosks as well. Not a big deal, but something we didn't think about at first (while focused on the wireless machines). This was a quick object lesson in The Law of Unintended Consequences. A good tip: test the whole system after making a change, even areas that you don't think you messed with.
5. And finally... some fun. Well, at least I think it's fun. I like codes and ciphers. I like stories/novels with codes and codebreaking in them. I have always liked creating codes and trying to break codes. To that end (and as an excuse to play with PowerShell), I wrote a PoSH script that encodes/decodes messages. I thought it would be fun to share a coded message and see if anyone can decode it. Here's the coded message:
- I added arbitrary line breaks to make it easier to post. The original output is all on one line.
- I am using a substitution cipher, following a new simple rules I came up with. These rules are fixed.
- I will post this message, re-encoded, again in the future. Having multiple encoding of the same message may help in decoding it.