Novell Cool Solutions

Doing stuff without thinking about it


February 16, 2007 1:45 pm





I have said it before, but there are a bunch of things that I just do without really thinking about them. And no, I’m not talking about the time I poured a gallon of petrol on a bonfire and then lit it with a very short match – I’m talking about GroupWise things. One of those things is updating GroupWise code on a server. It’s so intuitive to me that I stopped actually thinking about it years go, as have most of my colleagues in the GW team. It’s times like now, where everyone is trying to get the DST patches installed, where I actually stop and think about it.

So many people find it very confusing and it doesn’t need to be. There are a few golden rules but it’s pretty simple. Starting from the ground up. What to do with the service pack once you have downloaded it? If you extract the service pack and just run the install it will ask you for the location of an existing software distribution directory (SDD). Forget that. Quit the install. Start again. All of our service packs are a full build, minus a couple of key files – the .DC files. Just extract the service pack and then copy the DOMAIN and PO directories from your original media or SDD to the place you just extracted the service pack to. You are now the proud owner of a full overlay SDD to do whatever you want with. Got a bunch of other SDD’s out there? Just replace them with the shiny new one you just created. Burn it to DVD? Go ahead. Point at it and call it names? Feel free.

Now, this is just the first step in updating your servers. Most of you will now go and run the install, go though the graphical interface to update your agents, gwias and webaccess – forget that too. The installs want to collect a whole load of information that you already supplied the first time you installed them – you don’t need to provide it again as it already exists in either the GroupWise object or in the startup files. All we need to achieve is to update the NLMs, RPMs, EXEs etc. I’ll cover NetWare for now, and cover the rest later on. Open up your new SDD, browse to \AGENTS\NLM\ – here are all the binaries for your agents. You can simply copy them from here to location on the server that you run the agents from, normally sys:\system. Don’t copy the 2 directories though, instead open ‘Language’ and copy the contents to the same place you just copied the binaries. Do the same with ‘ldap’. You’ve now patched your agents.

1st Golden Rule:

If you have multiple GW components on the same server you need to update them all at the same time. This is because all of the components share files, specifically the GWENN. If you do not update them all at the same time you run a chance of getting Public Symbol errors and something won’t load.

So, with that rule said, how to update the GWIA and WebAccess? Simple, exactly the same way. For GWIA open up the SDD, browse to \INTERNET\GWIA\NLM\EXE and copy the contents to the server – the default is sys:\system again. Done. For WebAccess open the SDD, browse to \INTERNET\WEBACCES\NLM and copy the content, minus the ‘ldap’ directory, to the server – yep, sys:\system if you have a default install.

2nd Golden Rule:

If you are patching multiple GW components on a server stop them all, patch them and then start them all. By stopping them all you are ensuring that all the shared files are removed from memory so that the new instance is loaded instead of an agent trying to reuse the memory resident one.

Many of you are aware of the fact the WebAccess is a slightly special case, in that there are 2 components – the Agent and the Application. If you have followed along so far all you have patched is the agent. The agent, or GWINTER, comprises of the NLMs that you just copied. The Application is a Java application that runs in Tomcat and Apache. Run through the install for that one – it’s much easier and more foolproof than copying it manually, however, the agent and application do not need to be done at the same time, even if they reside on the same server. No sharing if files, so no need.

You’re probably still left with questions so let me cover all the ones I can think of and if you have more just post a comment.

How to install Hot Patches

Inbetween major service pack releases we will periodically post Hot Patches (used to be called FTFs). How to install those? Well, the rules and methods are exactly the same as I described above. The problem you face is that we don’t post them as a single, large download – we post the individual components. We do strive to post all the components at the same time, however, so that you can download them all and don’t run into the public symbol errors I mentioned above. So, make sure you update all the components on the server at the same time with the same level Hot Patch release. There may be times, like with the Rev E FTF for GW6.5 WebAccess, where we only post that one component. This is because there are no changes in any of the other agents so compatibility is not a problem.

Do I need to have my entire system at the same patch level?

Nope! Your system can be a complete mix of both major and minor versions. There are certain rules, for example an upstream major version client can’t talk to a downstream agent. For example, a 7.0.x client cannot login to a 6.5.x Post Office. A 7.0.1 client can happily talk to a 7.0.0 agent though. Also note that ‘client’ doesn’t just refer to the clients installed on workstations, it means anything that acts as a client. So, got POP and IMAP on GWIA enabled? Then GWIA is acting as a client to the POA, so a 7.0 GWIA can’t connect to a 6.5 PO. Same for WebAccess.

C’mon, I really only want to patch [insert component name here]

OK, I admit it – it is possible to only update a single GW component on a server. This is the exception that proves Rule #1. We normally don’t take you down this path as the potential to mess it up can be quite high if you don’t understand the concepts. This leverages NetWare address spaces. An address space allows you to completely isolate one agent instance from another – any required NLMs for that agent to run will be loaded into that address space. So, how to do it? Firstly, make sure each component is installed into a seperate directory – eg, on my test servers I have sys:\system\7agent, sys:\system\7gwia and sys:\system\7wa. Then you need to add each location as a search path – “search add sys:\system\7agent”, and so on. Then the magical command: load protected gwia @gwia.cfg, or load protected gwmta @mydom.mta. This will load the agent and dependant files, like the GWENN from the proper directory into the proper address space.

I am installing a new system, do I need to install GW7 and then patch?

Firstly, welcome to GroupWise. And to answer the question – no you don’t. If you follow the instructions up at the top to create a shiny new SDD you can create a new system from this. No need to create a 7.0 system and then apply the patches.

Is it possible to back out a patch?

Yes it is, and it’s incredibly easy. Just follow the same steps, and rules, you followed above but copy in older code instead of new code. A patch does not update any of the GroupWise databases, so there is no problem going forwards or backwards. OK, so there are some rules to this. You can’t go back major versions, so you can’t go back from 7.0 to 6.5. Also, I know I just said that patches don’t update the databases – not entirely true, our GW SP1’s often do. So it’s probably best not to go back from SP1 to an older 7.0 release, but there is no problem apply a recent Hot Patch and then going back to an earlier one, or 7.0.1.

How about an upgrade, same way?

Well, first define upgrade – an upgrade is going from one major version to another. The way I do an upgrade is as follows:

  1. Copy agents files to sys:\system
  2. Copy .dc files to the domain and po (making sure I put the right ones in the right place)
  3. Copy the view files from the client install dir to the PO ofviews dir
  4. Start the agents

What you will miss if you upgrade this way instead of running through the install is that the startup files won’t be updated to reflect any new startup switches we may have added inbetween versions. The install only ever enables 1 or 2 switches (/home and /cluster), so you won’t lose any functionality – you just won’t see what new switches may be available. You can find the startup file templates in the agent install directory \AGENTS\Startups\Language.

I ALWAYS run the install to upgrade GWIA and WebAccess and I never use the GWIA /copyonly switch.

Hey, you forgot to talk about Linux and Windows

Oops. Linux patching? Dead easy. Run the install and try to install one of the components that you want to update. It will tell you that there are a bunch of other components on the server and that they all need updating. Alternatively, copy all the .rpm files to a single location (with no other .rpms in there) and run the command rpm -Uvh *.rpm. You do not need to run the ‘configure’ options in the install.

Windows, same basic way as NetWare but just copy the files from the NT directories instead of NLM. Having a common version on Windows is actually less important than on NetWare as Windows will load the dependencies multiple times

Did I miss anything?

Oh, and yeah, my eyebrows eventually grew back. The dog was never the same though.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:Bill


    Thanks. Great article.

    Could your idea about creating a customized overlay SDD be used to migrate a GW 7.01 server? I will be replacing our current Netware 6.0 GW server with a new Netware 6.5 server soon. I’ve read the TIDs and Cool Solutions articles on migration, but thought you might have some specific advice apropos of your tips above.

  2. By:Alex Evans

    Without all the details I can’t really answer fully, but if you are moving from one server to another then you need to bear in mind that you don’t have all the startup files on the new server (and if you do they will probably need modifying to reflect the new server name). You can use the new SDD to install the agents from though – that’s probably what I would do.

  3. By:Matthew

    Since you opened the DST doorway – we are looking at applying the GroupWise patches for WebAccess but have a question – Do both the agent and the application need to be patched? the agent is running on a NetWare 6.5 server, the app is on a linux server.

    If it’s just the agent that will save us a great deal of time.

  4. By:Alex Evans

    It’s agent only.

  5. By:Martin

    BTW, You guys can Come along to the B’share presentation TUT254 on ZENworks server Management and GroupWise ( amongst other things) and see just how fast it can be rolled out too?

    For example one customer got to “Do” 400 servers in hours not days.

  6. By:Roger

    An excellent article!

    It seems to clear up a lot of issues that have been (and continue to be) raised in the forums and mailing lists. In comparison to what the patch/SP documentation suggests, could this posting be substituted?

  7. By:Alex Evans

    Yes it could – the instructions in the patch/SP docs are the foolproof instructions, but not the most time efficient.

  8. […] The observant amongst you will have noticed that SP2 came with a security flag on it.  We fixed a buffer overflow in WebAccess and people are asking what needs to be updated.  Well, the ports affected are 7205 and 7211, which are the GWINTER ports for communication with the servlets, and the HTTP interface – so the answer is the WebAccess Agent is the only thing that needs updating for this vulnerability.  Is it high risk?  In my opinion, no.  Most of you should have these ports blocked off from the outside world, only exposing 80 and 443.  I have not heard of this vulnerability being exploited. If you plan to update check out my previous thread on getting it all installed. […]

  9. […] Lastly, how to update – well I already blogged on this so I am just going to link you there and then add a couple of fine points specific to this update. […]

  10. By:gburg

    this looks a lot like the setup /copyonly, which i know works for the POA MTA and GWIA, not sure if it works for the WebAccess too.