Thursday, April 25, 2024

Does my small business need policies or procedures?

The simple answer to this question is yes, you do. If you have even a couple of employees, having some good guidelines is important so that everyone knows what they should be doing and what needs to be done. A small company will need very few, as it is easier to scale up than having nothing when an issue arises. You probably have a lot of them in your head, but other's need to know and understand them.

Having some documentation about some of the standard questions is a good idea because then everyone gets the same answer, which is very important. Some of the guidelines that should be outlined are:

  • Vacation – how much time off do I get and am I entitled to vacation?
  • Hours – what are the standard hours of the business?
  • Overtime – if I work overtime, am I paid for it in money or in lieu time?
  • Personal time off – is this allowed or is it again either my vacation time or I don’t get paid?
  • Sick leave – what is the policy about sick leave, one day versus many days?
  • Social media and personal communications during work hours

These are just a few ideas of guidelines that should be documented so that everyone understands what is required of them. Knowing that everyone has the same understanding is important because it means that everyone is working with the same knowledge.

When you are a small business, it is still a good idea to make sure that you have some documentation, even if it is just one or two of you. Documentation will help remind you of decisions that were made, or also what steps are required to preform a specific or infrequent task. Having some guidelines when you are a small business means that as you add or change staff, it is a lot easier to just continue adding to the guidelines instead of suddenly realizing that you don’t have any and everyone thinks differently about how things are done.

One of the biggest guidelines I am now noticing that maybe no one wants to address is the social media during work hours. Making sure that you have something that outlines what is and isn’t allowed in regard to social media. Can any employee post on behalf of the business, or is it up to one individual to do that posting. Can an employee spend quite a bit of their time checking Facebook, Instagram, TikTok or any other social media during their work hours? If checking social media is part of the job, sure it can be done, but it needs to have guidelines.

Having some guidelines and procedures is always a good thing so that everyone knows what is acceptable and what isn’t. It helps make the business run a little smoother because everyone understands what is expected of them. Sure, the guidelines and procedures don’t have to be as detailed as if you are big business, but they are still needed. It is harder to discipline someone for doing something you don't like if you don't have policies written down, communicated and available to all staff.

If you are uncertain where you should start, you can always reach out to us, and we will try and assist you in making sure everyone in your business understands what they should and shouldn’t be doing to support your business goals.

Thursday, April 18, 2024

Moving a GroupWise System

Through the life of a typical GroupWise system, it will likely move platforms at some point. No fancy migrations needed as all the database changes get done in place.

This could be hardware replacement, changing virtualization types, to hitting the limits of the OS at the time of the original installation. After all, you can only upgrade a box so much before there become issues with the OS. Even when you otherwise love that OS, a new install gains you so many of the advantages of it that are blocked in just upgrading it in place. Any GroupWise system of any real age has likely been moved a few times, such as from NetWare to NetWare to OES to OES

For this document, I will stick to current (late SLES15 era) and most common GroupWise hosting OS, with pure SLES or OES (built on SLES). Assuming GroupWise is the only application on the system so that the old box can be retired, and running an incremental copy of some sort. Imaging the data such as moving/copying a virtual drive can be done as well. This is for any and each server with a Domain and/or PostOffice on it. A GroupWise upgrade can be a part of this process if desired, but is assuming at least a GroupWise 2014 or greater source system.

This process allows you to build the new server in advance, and get the bulk of the files copied over in advance without downtime as those OFFILES are bulky, don't change much, and take a while (possibly many hours) for that initial copy. You are typically just looking at a couple of hours of downtime for the final move, under an hour if all goes smoothly.

Pre-migration is a good time to make sure your GroupWise maintenance is running properly, also check the results and files that are not part of the GroupWise system are removed from the GroupWise folders.

Build the new system with a different IP from the old server and a separate logical drive for GroupWise, either as NSS or XFS. Both are excellent options, both needing specific settings made, ideally at creation. NSS needs Salvage turned off, XFS (or any DB safe Linux type) mount points need the noatime and nodiratime set for optimal performance.

  • Install GroupWise, but do NOT configure it!
  • Restart the server at least once before the final migration to really finish that install.
  • Copy the data with either rsync or dbcopy. rsync is very native with any Linux and is worth knowing for all platforms. I find it is the faster and easier of the two. It does every file that has ended up in the source (junk included) and doesn't get you restorable db files if the GW Agents are running, which is not a problem with such a migration. DBCopy requires a mount point to the new location to work, only does GroupWise files, is slower, and doesn't delete files. A script of the combination of them make for a decent low budget backup. Example in the Community.  
  • Both tools can and the one you choose should be used incrementally, with a primary full copy of both the Domain and PostOffice folders, making sure the size at the destination is about what you see on the source. Identify any notable differences, as there may be issues to take care of. You can/should do this in the days leading to the actual flip outage of a couple of hours. If different versions, it tends to be best to use the newest dbcopy if you are using it, otherwise the direction of copy doesn't matter much.
  • Easy comparison tools:
  • # du -h --max-depth=1 /GWdomain|GWpostoffice (the PO will take a while due to OFFILES)
  • or install and use ncdu from GWdomain|GWpostoffice folders

  • Is your GroupWise system the same IP as the server it is on, this is where we will change that. It makes these moves so much easier, is mandatory if you were to go to cluster services (where I learned this trick), and is how the containerized future of IT generally works.
  • On the new server, make sure the /etc/hosts file has the GroupWise agents as FQDN entries as needed for GroupWise since 18.4, and that they match what you have in the agents' settings.

  • On the new box, make sure the GroupWise agents ports are all open on the Firewall. Firewalls on servers are becoming less and less an option in the whole Zero Trust path of things.
  • Firewall ports references
  • on MTA system: 7100, 7180, 9710
  • on POA system: 1677, 8301, 7181, 7101, 7191, 9711,
  • on GWIA system: usually an MTA set and 25, 9850
  • For the final migration, make sure the source server's agents are shutdown, and preferably can't be turned back on
  • # rcgrpwise stop
  • # systemctl disable grpwise.service
  • perform the final sync
  • While that final sync is running, copy the following files to the new system.
  • /etc/opt/novell/groupwise/gwha.conf
  • /opt/novell/groupwise/agents/share/gwdva.dva
  • /opt/novell/groupwise/certificates/*
  • # scp /etc/opt/novell/groupwise/gwha.conf root@DestinationServer:/etc/opt/novell/groupwise/
  • scp /opt/novell/groupwise/agents/share/gwdva.dva root@DestinationServer:/opt/novell/groupwise/agents/share/
  • # scp -r /opt/novell/groupwise/certificates/* root@DestinationServer: /opt/novell/groupwise/certificates/
  • Once the sync is complete, remove the secondary IP from the source server if already using such, or down that server.
  • Add the secondary IP to the new server
  • # systemctl status grpwise.service
  • may not be enabled yet. enable it and start it
  • Test system, can you send & receive email, and manage the system
  • A reboot to make sure it all behaves is a good thing as well.

If this feels overwhelming, and you are in Canada, please reach out to us, as we can help. For other feedback and comments, post a comment below.