At work we’re upgrading from an older, sunset-ed version of our LMS to the latest service pack of the more recent version. We’ve been going through the upgrade for Vendor X for the past eight weeks, and up until last Thursday it was like a dream — nary a glitch to be found. We started the move on our Production server to make the switch last Thursday night, and that is when our tune took a sour note.
We’ve been experiencing a host of content issues — not SCORM communication issues, mind you. Content. Like, the first time you launch a course, everything works just right. If you close a course and it bookmarks your progress, logging back in (depending on the content) you get the interface, but you don’t get the actual content. In some courses, this breaks the content outright and there’s no way of getting it back.
At first, we were (I was) thinking it was some weird kind of security issue where it was treating Flash content recently run as a security risk and locking it out on subsequent sessions — but this was quickly dispelled, since multiple users could log in after the initial blockage and see all the content the first time they would experience it in their own login. Then, we thought that the scope of it was contained inside our firewall, so we started to divert traffic to our external content server — but that, too, started showing the same issues. So while it’s not ruled out as a factor, our network environment isn’t the only factor involved.
Currently we have a theory that there’s a security setting that’s scrubbing data sent to the LMS by content, escaping characters and such. And it’s doing that on content that is, on its own, escaping characters (like what Articulate does). And that may be underneath whatever Tomcat or IIS is doing to filter data for malicious strings. So, perhaps with all this filtering of the data, something breaks down when the feed comes back. We can trace the string coming back on consecutive data transactions with SCORM content and that’s definitely going on — pipes (|) are being sent the first time. Then, when they’re coming back, they’re URL-encoded. Then it looks like the URL encoding is changing the Ampersand (&) into something else… so it’s being URL-encoded in one place and then that URL encoding is being treated as a straight-up string by something else.
Which for you non-technical types — is un-good.
Everyone is working very diligently to figure this out, but I predict quite a few help desk calls today (I don’t get them, but I know they come). And with members of the team having invested so much time and effort, it’s a drag to see the snags come in so late in process.
I’m pretty confident that everything will be fixed — it’s only a matter of time, as are all things digital. But it’s a drag, and that is no doubt. It’s not a matter of finger-pointing — it’s not Vendor X’s slip-up or anyone’s negligence — this is just a point of pain that comes with enterprise software, especially since enterprise software generally has to be configured specially for an enterprise’s unique needs.
I know I’m not the first (nor will I be the last) to witness it, but I feel horrible for other members of the team who have put in so much time — only to find out they’re going to put in a lot more time 🙁