Sometimes we get it wrong. The rollout went about as well as it could go. I’m still frustrated by the fact I had to manually deploy the print client to our users and that the software wasn’t any sort of identity- or directory-aware. Getting a executable file that’s coded in the installer for each user? That’s not nice. Requiring administrative permissions to install that? Go away or I shall replace you with a very small shell script.
What ultimately doomed the rollout for me was that we had users who had sporadic and random issues. There were no common threads among those who had printing errors (other than, presumably, they were trying to print and the day ended in y), so troubleshooting was next to impossible.
Since printing’s kind of a mission-critical task where I am, we made the decision to abandon Hive and go back to MF. And I’m fortunate that I have supportive management and colleagues who understand that sometimes, you get it wrong.
A return of the Friday Five and some of my observations on PaperCut Hive, a software stack I’m currently deploying
Where I work, we’re almost complete with a migration from PaperCut MF on-premises to the fully cloud PaperCut Hive product. For the most part, I’m pretty pleased with how it’s gone and how it supports some of our organization’s transition goals to less on-premises. But there are some things that have been some definite head-scratchers in the process.
1. There’s no migration. That’s right: there’s no migration. Any data or user provisioning settings in MF don’t transfer over. You’re starting from scratch. Do you have RFID badges for your employees that they use to authenticate to the copier or MFP? Gone. Custom scan locations? Gone. While I’m thankful that I have a small number of colleagues and they have been more patient with me than I deserve, imagine if you have to have hundreds or thousands of employees re-authenticate on the new system. At least it’s a one-time only process.
2. There’s an app, but you don’t need it. PaperCut makes a big push to have users download their app for print management. I have issues with making people download company software to their own personal smartphones. Thankfully, even though PaperCut makes this push, you can ignore them.
3. Communicate early, often, and concisely. One of the questions I received a lot was about why we were doing this and how this would affect them. Fortunately, by planning the deployment, I was able to say that except for two initial tasks, everything would remain the same. And I told them why this change was being made, which was to support our organization’s future technology stack.
4. If you have multiple copiers/printers/MFPs, don’t move everyone over all at once. Keep both printing systems running in parallel so that you don’t have to sweat it having some users unable to use the printers and you have to rush the migration. By having some machines on the new system and some on the old system, you don’t have to be so aggressive in moving everyone over.
5. What automation? What year is it again? There is no way to use automated tooling to deploy PaperCut Hive software to our colleagues’ computers. To install the software, I had to go to each machine, download the unique software that PaperCut generates for each user, install it using my administrative credentials, and go on. That worries me, because that means the software is not directory aware and also means that I can’t include it in a base deployment configuration. While I’ve heard that this may change in the future, had I known this limitation, I would have postponed our deployment until later.
Those are some of my observations about this. It’s been received well by my colleagues, but some of the initial challenges made for a fun week.