Check the GMS admin interface at https://yourGMSserver:8120, log in with root. The Dashboard flag issues in red with appropriate bolding and icons to be readable with a monochrome display/eyes.
On 18.2 and earlier, run dsapp's "General Health Check" (under "Checks & Queries") as that can quickly point to a number of possible things that need fixing. In addition to the menus, you can also get the health check with the command line "dsapp -ghc", with other such switches available in the dsapp wiki for more advanced use.
On 18.3+ increasingly dsapp functionality is being incorporated into the mcheck tool, server:/opt/novell/datasync/tools/mcheck # python3 mcheck.pyc
At least once every six months (as per KM000002141 (old TID 7009453)), Vacuum and Re-Index. Launch dsapp, select Database | y to stop Mobility services | Vacuum Databases, then Re-Index Databases.
Make sure the system's or user's databases are OK with a couple of Contents Analyze/fixes. If there are any errors after two runs, you need to look into them. If you are running automated GWchecks (which you should be doing), then look at the most recent Contents check for any problems on that user and dig into those as you would as part of your regular log review
Run mcheck on the user as per the documentation.
- cd /opt/novell/datasync/tools/mcheck/
- python mcheck.pyc
Check the log files as per the documentation. The TUT7879 Presentation slides from BrainShare2014 help guide you to which of the log files to focus on in addition to lots of other useful troubleshooting tips.
- /var/log/datasync
Before contacting support, posting in the forums, or other such request for help, it is worth including the exact versions you are working with. The output of the following commands contains the needed version detail.
cat /etc/*release
rpm -qa |grep group
Support has put a nice Troubleshooting video together that is good to run through when you have time to watch and pause often as you explore your system with what they describe.
Make sure the user isn't trying to actively use the Frequent Contacts address book as that is something that should be flush-able and is gone in GW 2014 and forward.
If the above doesn't do the trick, do an export of the user's address book, rename the old one, create a new one with the old name, import that exported file into this new address book, check the settings for address books in GMS and then see how the user is doing.
If all devices are affected, make sure you can connect to https://yourGMS.yourDomain.com:433. This assumes the default port, change to match your system. Check that the SSL certificate hasn't expired.
What does the GMS admin interface at https://yourGMSserver:8120, show about the user(s) in question?
If certain classes of devices are affected, is your GMS's certificate self minted? Some devices just don't like the self minted certs and you need to pay for one tied to a known trusted root/CA. If you went with a small or very new Certificate Authority (CA), you could also hit issues of the devices not yet knowing about the CA yet.
- Microsoft's test tools includes ActiveSync tests that apply to any ActiveSync system, so just pretend your system is Exchange.
- General SSL cert checkers: Qualys,
Comodo,
Symantec. Worth saving the results of all three as you check them occasionally.
If there is a mismatch with the full name (FQDN) of the host itself, the cert, and how you point the devices to GMS, then that can cause problems as well. TID 7014481 can help at least part of the way.
GMS starts alarming when it runs below 20% space free, and just stops running at 10% or less free, so you need to pay it a little more attention than you might other systems. There are three areas that can take a lot of space:
The Database at /var/lib/pgsql does tend to grow over time. Regular vacuuming and re-indexing will help manage it, but it appears that there is value in doing a full flush and repopulate every few years. dsapp's CUSO (Clean-Up Start Over, under Database in dsapp) is the easiest, in-place method, or is a function of replacing one GMS with another.
Log files can grow substantially in /var/logs/datasync, especially if you left them at a diagnostic setting (don't leave any logging in diagnostic for longer than a specific test). TID 7010533 worth checking to help here.
Attachments in /var/lib/datasync/mobility/attachments tend to be the biggest area for many sites, especially if you've raised the maximum size of attachments.
A way to automatically track snapshots of how space is being used is to put the following script into your GMS server's /etc/cron.monthly folder.
#!/bin/bash
# This file is to grab regular GMS specific drive usage details and save it in
# /var/logs/datasync/spaceuse.log
# Put this file in /etc/cron.monthly, chmod +x it, and chown root it
# then it should run automatically.
# original from http://www.konecnyad.ca/andyk/gwmobility.htm
#
date >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
df -h >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
du /var/lib/pgsql -hx --max-depth=1 >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
du /var/lib/datasync/mobility -hx --max-depth=1 >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
du /var/log/datasync -hx --max-depth=1 >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
echo -------------------------------- >>/var/log/datasync/spaceuse.log
echo >>/var/log/datasync/spaceuse.log
A common cause of sync problems is when a user has moved (whether a mousing oppsy or deliberately) one of the primary folders to an unexpected location, or other folder oddities that don't otherwise both the regular client but do trip up GMS. A regular Contents GWcheck will fix many of these, but of course we only run that every week or so and they don't get all the causes. If a manual Contents Check on a user hasn't fixed this, try one with RESFLDR in the MISC tab (other relevant MISC options, one at a time are: deldupfolders, resequencefolders, pabfix. Read up on them before using). If a user keeps messing this up, you will have to educate them that the system needs those main folders (Mailbox, Sent Items, Calendar, etc...) to stay where they are put in the system. dsapp has a check for this, as of v243 the steps are: 5. User Issues, 2. GroupWise checks options..., 2. Check GroupWise folder structure, enter the user/group ID.
If you replacing a large number of devices, this is a good time for a new GMS server if that was already in the works. We've seen that window of new extra devices syncing while the old are still on being a very high load slowing things down.
For major migrations including SLES, easiest is to create a new vm with the new SLES, create the mobility partition as an XFS system, install the new GMS, configure it including adding the users. Once they've finished Syncing, then flip the NAT / DNS over to the new one and once that is complete you can start the decommissioning of the old by removing the users from it first. Laura wrote the basics in the Community that is now expanded in in the documentation.
Sometimes you may need to set the logs to debug. While old with some out of date references TID 7006823 mostly points you to where to change them
