This series focuses on the various impacts the underlying operating system can have on your OL Connect implementation. This chapter explores some of the effects of upgrading your version of Windows.

First, something completely different!

Like many, over the past several months I’ve been working from home because of the global circumstances. I’ve set myself up in a comfortable home office, with a fairly powerful desktop computer than can flawlessly handle any work-related task in the daytime, and a combination of Netflix and Flight Simulator during my off hours. Each morning when I log on, all my standard work-related apps launch: Outlook, Teams, the corporate VPN, Notes, Docker, etc. and I can usually start working within a few seconds.

So the other day, I turned on my computer while sipping my obligatory cup of morning coffee. One of my first tasks each morning is to look at my JIRA board to check on the development of our products. Since we have a global team, JIRA tickets are being modified almost 24/7, so I always have a healthy list of items to review.

But that morning, when attempting to access JIRA, I was presented with the disconcertingly terse “Hmmm… can’t reach this page” message. “Well“, I thought, “good morning to you too, computer“… Not being one to get phased by computer tantrums, I immediately checked the status of my corporate VPN, which is required for me to access JIRA. And lo and behold, it was turned off, which I found a bit peculiar. But hey, bits happen, so I just asked it to connect again. And then the little cursor started spinning… and spinning… and spinning. I rebooted (a few times), tried to reconnect (several times) and drank more coffee (too many times) but to no avail: I just wasn’t getting logged on to the corporate network. Which, when you’re working from home, is kind of a bummer, to put it mildly.

Being the seasoned professional that I am, I did what all my years of training have taught me: I picked up the (virtual) phone to call our IT department and feverishly reported that I couldn’t get on the corporate network. I explained in no uncertain terms that this was a tragedy of epic proportions and that unless this issue was fixed right away, heads were gonna roll! Not that I have any say in those kinds of managerial decisions, mind you, but I needed to threaten somebody, somehow. Such is human nature.

Fortunately, our IT department staff are used to calmly dealing with over-caffeinated colleagues and started by asking me what changed on my machine. “NOTHING !!!“, I said, “it worked yesterday and this morning the VPN won’t connect“. Long story short: we checked everything out and IT finally identified the cause of the issue: a Windows update had been downloaded and installed on my machine overnight. To quote them verbatim: “The thingamajig driver for the doohickey peripheral created a whatchamacallit conflict with your doodad“. Granted, I may have gotten a few of those technical terms wrong, but that’s the gist of it.

“Nothing changed!”

This kind of stuff also happens regularly to our Support team. One of the phrases they hear most often is “OL Connect is not working anymore“. Which, in all fairness, is usually true: the process used to run but no longer does, so the quick conclusion is that OL Connect broke down on its own. And one of the very first questions our Support crew asks users under those circumstances is “What changed?“. After all, if a process that has been working consistently for weeks, months or years suddenly stops working, there has to be a reason for it.

Something must have changed, somewhere. Something like a Windows update, for instance. Or perhaps an Office update. Or a Windows group policy change. Or a thingamajig doohickey.

Windows updates have been known to cause issues with software that runs on top of it. That’s not to say that Windows is buggy or that Microsoft is not thoroughly checking its updates before distributing them: au contraire, in most cases, the changes are for the better. They just happen to conflict with existing software. Say, for instance, that a Windows update installs a more robust version of the Windows Firewall or of Windows Defender. It could take you a while to figure out why the OL Connect server is no longer able to communicate with some other server on the network because that particular port is now blocked. Or why an operation now takes much longer because some heavily used folder is now consistently being scanned for viruses.

Some updates have more insidious effects: they don’t necessarily impact a specific server, but rather the entire network architecture. Think of group policies, company firewalls or Active Directory updates, for instance.

So before stating that nothing has changed, make sure to look at your Windows Update history. And talk to your IT people. You know, just in case.

“I updated OL Connect and it’s now too slow!”

Let’s get one thing out of the way: we, at Objectif Lune, pride ourselves on the work of our QA team. These guys and gals relentlessly examine all the nooks and crannies of our applications, in search of the most elusive bugs. And they regularly return the results of their tests to R&D with a “HA! Found one!” note attached. But their most important task, by far, is to perform regression testing. In other words: backward-compatibility tests. With each new release, we strive to achieve maximum backward-compatibility with previous versions. To be perfectly honest, if we didn’t care at all about backward-compatibility, we’d be able to release new versions several times a year. That’s because implementing a new feature is relatively straightforward, but integrating it into an existing ecosystem is a much, much more delicate task.

So when we get a report that OL Connect slows down or stops working altogether after it was updated, we take it very seriously. After all, if one user reports it, that means it could possibly affect other customers, perhaps even all of them! And that would be catastrophic.

DISCLAIMER: this article does not claim that Objectif Lune manages to achieve perfect backward-compatibility with each new release. Some issues may still creep into a new release, even after going through the most stringent QA process. We’ll be describing the R&D and QA processes in a future article. But for the purposes of this article, let’s assume that backward-compatibility is not the issue. 

So… what else changed?

One of the most common things we find when we receive reports of issues caused by OL Connect update is that the user has jumped from a much older version of OL Connect (or even, of PlanetPress Suite!) to the most recent version. Now that, in and of itself, could be a concern: if both versions are separated by, say 6 releases, then there are potentially 6 levels of backward-compatibility issues to consider. But again, let’s assume backward-compatibility isn’t a problem in this particular instance.

But another thing we find when users perform such a massive upgrade is that they also switched Operating System versions. In fact, in many instances, users are forced to update the OS (usually because their current version is no longer supported by Microsoft) and then, instead of reinstalling their existing version of OL Connect, they take that opportunity to reinstall the very latest version of OL Connect.

And that’s when things become confusing: Version A of OL Connect on Windows B worked just fine, but Version Y on Windows Z is slow as heck. In some instances, we’ve actually received reports of the software being three times slower after updating both the application and the OS. That’s obviously unacceptable. And our Support team can usually confirm the factuality of these reports after examination of the OL Connect logs: the logs don’t lie, and they do show a degradation of performance!
To boot, our users will often report that none of the other applications on the server have suffered from any performance degradation. Which is proof, in their eyes, that OL Connect is the sole culprit.

The search for the guilty party

The problem, however, is that we’re now comparing apples and oranges: Old application+Old Windows against New application+New Windows. Also, OL Connect performs tasks that very few – if any – other application on the server performs, so it is not impacted by the OS in the same way that others are.

The proper way to test this would be to install New application on Old Windows, and then we could compare the logs of both the new and the old applications. The same goes if we install Old application on New Windows. This would give us a common basis for comparison, but that’s usually not feasible once the upgrade has already been performed.

Still, this kind of testing should be mandatory prior to upgrading any major system. OL Connect is often considered an essential, business-critical component of an organization’s IT architecture. Any major upgrade should therefore be tested before being put in production, and that includes performance testing.

Case in point: around 2015, several of our users moved from their trusted Windows Server 2003 (which was being end-of-lifed by Microsoft) to the then-current Windows 2012. Win2012 was a more than adept upgrade, offering a slew of new features and functionalities (click here to get a sense of the breadth of changes between both versions). But for some of our users, this translated into a significant drop of performance in PlanetPress Suite (that was before OL Connect). After a lot of investigating and googling, we found the problem was due, in part, to how Win2012 accesses the internal storage: disk-intensive applications (like PlanetPress Suite) were negatively impacted, while memory-intensive applications benefited from a boost in performance. Which just goes to show we can’t compare the behavior of different applications on different OS’es.

What does Objectif Lune recommend?

Whenever you plan on upgrading your Operating System, first do so on a Test system by installing the new OS and then reinstalling the same applications that are found on the Production server. This will allow you to test for functionality and performance issues. Once you are satisfied that your “old” software runs as expected on the new OS, then you can proceed with the upgrades to individual applications. You should do so one at a time, to make sure newer versions of applications don’t impact each other. Yes, this is a time consuming process, but one that is critical to ensure you don’t run into major issues when you upgrade your Production server.

Each step of the way, record everything you’re doing so that when the time comes to upgrade the actual Production server, you’ll know exactly what to do, which will minimize down-time.