thebackroomtech » ConsoleOne

Fix: Groupwise Login Failed Login Rejected (8219)

admin — Thu, 18 Jun 2009 10:43:53 +0000

Specific Error Message shown in the Groupwise 7.0.3HP2 WebAccess log file:

Login Failed: User PO5 Groupwise login rejected (8219)

Two of my post offices could be accessed via WebAccess, while four could not. I was pretty sure the problem was with domain or post office links. I doubted the problem was with the domain links, since one of the post offices that could be accessed through WebAccess was in the same secondary domain as three post offices that could not.

The solution was to edit the Groupwise WebAccess object’s post office links in ConsoleOne. All six of my post office access mode links were set to Client Server only.

For the four post offices I could not access through WebAccess, I changed the links to Use Current Post Office Address, restarted WebAccess, and verified I could login to each of the problematic post offices.

I then changed the links from Use Current Post Office Address back to Client Server only, restarted WebAccess, and verified I could login to each post office. My 8219 errors were no longer listed in the WebAccess log file.

Fix for ConsoleOne Error -634 The target server does not have a copy of what the source

admin — Thu, 05 Feb 2009 14:24:06 +0000

Error seen when attempting to authenticate to eDirectory in ConsoleOne on SLES 10 Linux:

(Error-634) The target server does not have a copy of what the source
server is requesting. Or, the source server has no objects that match
the request and has no referrals on which to search for the object.

The SLES Linux box does not have eDirectory installed on it.

The solution is, instead of specifying a tree name, specify the IP address of a server with a RW replica to authenticate to. Specify the IP address in the tree field of the Novell Client login screen.

Novell TID 3801441 Is Wrong! – How to create a GroupWise user with a specific File ID (FID) for accessing an archive, or restoring a deleted user

admin — Tue, 27 Jan 2009 13:54:34 +0000

I was trying to re-create a Groupwise account this morning, and was having great difficulty in changing its FID per TID 3801441. Here’s what Novell’s instructions are as of today, January 27 2009:

Follow these steps to create a new user with a specified FID number.

First you will need to create a new user account in GroupWise using any user name / user ID you choose. You may already have the NDS user account and do not have to delete this account but rather just add a GroupWise account to it. If the NDS user already has a GroupWise account you can either disassociate the GroupWise account from it of delete just the GroupWise account from the NDS user.

Do not log in to the account via the GroupWise client. Follow the steps below before allowing the user to log in to GroupWise in order to change the FID of the existing user to a specified FID

To change the FID for the user:

1. Open the properties of new GroupWise users account in ConsoleOne, click the arrow on the GroupWise tab and choose account, note the users current FID in the middle of the GroupWise account page. Click on the ‘Page options‘ button in the lower left hand corner.

2. In the “Tabs and Pages” window expand the ‘GroupWise‘ heading and choose Account. Highlight account and click the Disablebutton. Save the setting and exit the GroupWise users account by selectingOK/OK. This disables the GroupWise account Tab and moves the GroupWise information to the Other Tab where we later are able to modify the FID.

3. Close the GroupWise users account (Cancel or X) and then re-open it. Go to the Other Tab and the GroupWise attributes are listed as ‘Leftover attributes that are not handled by custom pages‘.

4. Click On the NGW: File ID attribute and Edit it to the specified FID / three unique characters / letters or numbers and then save by clicking ok.

5. Now go back in to the ‘Page options‘ button in the lower left hand corner from step #1 and enable the GroupWise account options you previously disabled.

6. Close and re-open the GroupWise users account and note the FID on the GroupWise account tab has been changed to the FID you specified.

The directions are ALMOST correct, except step #2 states that after disabling the Account tab, you should be able to modify the FID by viewing the NGW: File Attribute on the Other tab, under Leftover attributes that are not handled by custom pages. This is not correct!

You have to disable the Identification tab, not the Account tab, in order to view and modify the NGW: File Attribute, aka FID. Only took two hours out of my day to figure that out. I thought the problem was with my ConsoleOne or Groupwise snapins. I can’t believe this TID has been around since 8/22/2007 and has not been corrected.

FWIW my environment is Groupwise 703HP1 with ConsoleOne 1.3.6f.

Fix for ConsoleOne.exe error – The procedure entry point WpSUDataLength could not be located in the dynamic link library gwenv1.dll

admin — Tue, 18 Nov 2008 11:02:46 +0000

Some of our administrators received the following messages when launching ConsoleOne 1.3.6f after updating to Groupwise version 7.0.3 snapins from version 6.5.5:

The procedure entry point WpSUDataLength could not be located in the dynamic link library gwenv1.dll.

and

An error occuring during ConsoleOne Startup. ERROR: java.lang.UnsatisfiedLinkError: ititIDs

The fix was to copy gwenv1.dll from the Groupwise 7.0.3 client’s software distribution directory’s \win32\system32 directory to the local administrator’s c:\novell\consoleone\1.2\bin directory.

You must ensure gwenv1.dll file is version 7.0.3. Also check c:\windows\system32 for existence of prior version of gwenv1.dll.

You can read about other gwenv1.dll issues I encountered that deal with the Groupwise client and Blackberry Enterprise Server (BES).

Fix: “Use GroupWise user address as Mail From: for rule generated messages” checkbox in grayed out in ConsoleOne

admin — Mon, 10 Nov 2008 10:44:06 +0000

In my ConsoleOne 1.3.6f running Groupwise 7.0.3 snapins I was unable to select the “Use GroupWise user address as Mail From: for rule generated messages” option. The check box was greyed out.

To fix this, I had to view the properties of the GWIA object. On the Groupwise Identification tab I manually changed the Database Version from 6.5 to 7.0.1. Once I applied the change, the check box became selectable.

Still not sure why the GWIA database version did not adjust itself after our Groupwise 6.5.5 to 7.0.3HP1 upgrade.

Creating eDirectory SSL certificates with alternate names to use across round robin DNS load balanced web servers

admin — Tue, 14 Oct 2008 11:23:16 +0000

We have three internal Apache web servers that we use for Groupwise webaccess 7.0.3. Each server will be accessed acrossed our intranet via round robin DNS at https://webaccess/gw/webacc for email. When users currently access this URL they are getting Internet Explorer Security Alerts, stating:

The name on the security cerrtificate is invalid or does not match the name of the site. Do you want to proceed?

In order to fix this issue, I need to install SSL certificates on each individual server and configure Apache to use the new certificates. I also needed to configure my web browser to trust the issuing Certificate Authority.

I chose to use our existing Novell Organizational CA to issue the certificates rather than purchase one from Verisign or other Trusted Root Certification Authority since these sites would only be accessed across the corporate intranet.

We had one additional requirement – each server still needed to be accessed via https at https://servername for Novell Remote Manager and iManager. This meant the three servers had to have valid SSL certificates for multiple host names, i.e. both their actual name and the webaccess name.

The Environment

Three Netware 6.5.5 server running Apache 2.0.54 for Netware. Servers are named web1, web2, and web3
ConsoleOne 1.3.6f
Novell Certificate Server Snapin version 2.21 Build 28
Internet Explorer 6 web browser

Creating the server SSL certificates

1. Launch ConsoleOne

2. Browse to the OU that holds the servers you wish to create certificates for.

3. Right click on the server OU

4. Select New – Object – NDSPKI:Key Material – OK

5. Select the server name you want to create the certificate for, and give the certificate a meaningful name. I named mine intwebaccessweb1

6. Under Creation Method, select Custom – Next

7. Select Organizational Certificate Authority will sign this certificate – Next

8. Accept the defaults of 2048 bit key size, SSL or TLS type, and allow the private key to be exported – Next

9. This is an important part – The subject name must match how you will be accessing your server over https for iManager and NRM. Click the Edit button, then click the double arrow button to the right of the subject name. This will move the .CN= portion of the name to the left side of the box.

Replace everything from .CN= to .OU= (or .O=) with the name you will be accessing your server with.

Since I will be accessing my server at https://web1, I used .CN=web1.O=myOrg.

If you will be accessing your server for iManager, NRM, or other non-shared services at https://www.yourdomain.com you would enter .CN=www.yourdomain.com.O=yourOrg

10. Press OK to accept the subject name.

11. Change the validity period to what ever duration you would like your certificate to be valid for. I selected maximum, which will make it good until the certificate for my Organizational CA expires.

12. Press the Add Name button – here is where we specify our secondary name we want the SSL certificate to be valid for.

13. Highlight the existing Directory name and press Delete.

14. Click Create – DNS Name

15. Specify the host name you will be sharing amongst your web servers. This is sometimes referred to as a DNS Subject Alternate Name

I specified webaccess – OK – OK – Next. Again, if you will be accessing your shared web server at https://www.yourdomain.com, specify www.yourdomain.com as the DNS name.

16. Select to associate this server certificate with Your organization’s certificate – Next – Finish

I then repeated these steps for my other two web servers, replacing in steps 5 and 9 ‘web1′ with ‘web2′ and ‘web3′, which are the real host names of my other web servers. Step 15 remains the same, since this is the common name I want all three web servers to respond to.

Configuring Apache to use the new SSL certificates

1. On the first web server edit the sys:\Apache2\conf\httpd.conf file.

2. Replace the line reading

SecureListen 443 “SSL CertificateDNS”

with

SecureListen 443 “intwebaccessweb1″

where intwebaccessweb1 is the name of the web server you created in the section above. Note that the certificate object will be displayed in ConsoleOne as ‘intwebaccessweb1 – web1′. Do not include the hyphen and server name, i.e. ‘ – web1‘ in the SecureListen statement.

3. Save the httpd.conf file

4. On the web server console, run ap2webdn to unload Apache

5. On the web server console run tc4stop to stop Tomcat

6. On the web server console, run tckeygen to update the keystore data. Switch to the logger screen to verify the process completes before proceeding to the next step.

7. On the web server console, run tomcat4 to load Tomcat. Switch to the logger screen to verify the process completes before proceeding to the next step.

8. On the web server console, run ap2webup to load Apache.

9. Browse to the shared name of your web server, https://webaccess/gw/webacc in my case. Note that you will still receive the Security Alert pop-up until you install the Organizational CA certificate into your Trusted Root Certification Authorities store, which I’ll document tomorrow.

10. On the Security Alert pop-up, you should see the message stating The security certificate has a valid name matching the name of the page you are trying to view.

This means your SSL certificate is valid for the host name shared by the web servers.

11. Browse to https://web1, which is the host name of one of your web servers defined in step 9 of Creating the server SSL certificates.

Again, you’ll still receive the Security Alert until you install the Organizational CA certificate into your Trusted Root Certification Authorities store, but you should see The security certificate has a valid name matching the name of the page you are trying to view. This means your SSL certificate is valid for the host name for this specific web server.

Here are the instructions for installing the Organizational CA certificate into your browser’s Trusted Root Certification Authorities store, which is the final thing we’ll need to do to rid ourselves of the Internet Explorer’s Security Alerts.

“Error -618 – The Server has detected an inconsistent database” when trying to view an eDirectory object’s properties in ConsoleOne

admin — Fri, 10 Oct 2008 09:10:44 +0000

When trying to view a Groupwise Distribution List in ConsoleOne, I received the following error:

-618 The Server has detected an inconsistent database. Usually this means that the number of entries in a container does not match the number stored in the container’s entry

This message indicates an eDirectory problem. To repair this object, I did the following:

1) Launched a web browser and logged into iMonitor on the master replica server at:

https://nds-nw1:8009/nds/

2) Browsed to and selected the problematic .allstaff.groupwise.corp Distribution List object

3) Clicked the monkey wrench icon to perform a single object repair

4) Selected repair single object –> Start repair

After performing these steps the -618 error persisted, so I logged into iMonitor on the eDirectory R/W replica at:

https://ndsrw-nw1:8009/nds/

I performed steps 2-4 on the R/W replica and I was then able to view the Distribution List membership and verified C316 was listed as a member. The -618 error was gone.

Fix: ConsoleOne error “GWIA Admin could not locate file exepath.cfg”

admin — Thu, 09 Oct 2008 09:15:58 +0000

The ConsoleOne error “GWIA Admin could not locate file exepath.cfg” when editing the GWIA object is generally caused because ConsoleOne cannot find the gwia.cfg file.

Exepath.cfg is usually found in the domain\wpgate\gwia directory on the GWIA server. This simple file should only contain the path to directory where gwia.cfg is located. On Netware servers, this location is typically the sys:\system directory, so the exepath.cfg contents usually look like:

\\servername\sys\system

On occasion I have seen this path use a mapped drive letter instead of the UNC path. If you are experiencing this problem, replacing the drive letter mapping with the UNC path should fix this error.

Today I received this “GWIA Admin could not locate file exepath.cfg” error when I tried to access one of my GWIA objects from ConsoleOne 1.3.6f. I just upgraded GWIA from version 6.5.5 to 7.0.3, so I suspected that conversion may have altered the exepath.cfg file. But to my suprise, the file was identical to the pre-upgrade version.

I was finally able to resolve this problem by mapping a drive on the workstation running ConsoleOne to the GWIA object’s domain directory. This mapping seems to help ConsoleOne find the exepath.cfg file, which tells it where to locate the gwia.cfg file.

Incidentally, if you are receiving this error on Linux, you may want to refer to:

TID 10095505: GWIA Admin could not locate file ‘exepath.cfg’ which suggests verifying the case of the paths are all lower case, since Linux is case sensitive.

TID 3458009: Error: “Could not open EXEPATH.CFG” when attempting to view GWIA properties in ConsoleOne suggests ensuring the UNC path is typed in a Linux friendly format.

Howto: Find eDirectory SSL certificates and determine when they expire

admin — Tue, 30 Sep 2008 15:04:27 +0000

I’ve recently experienced some challenges releated to expired eDirectory SSL certificated on my Netware and OES servers. I came across TIDs 10098567 and 3814248, which describe methods of querying eDirectory via LDAP to find expired or soon to be expired certificates.

I was going to give these methods a try until I realized they required adding attributes to eDirectory by extending the schema. I’m not wanting to rock the boat right now, so doing anything that could potentially have a negative impact on network availability is something I want to avoid.

Here’s the manual way I searched for eDirectory certificates. I verified their expiration dates manually, which is a boring and repetative (but safe) procedure.

Launch ConsoleOne
Highlight the NDS tree to search
From the Edit menu select Find
Check the Search Subcontainers check box
Set Find Type: Advanced
Select [Object Type] = NDSPKI:Key Material
Press Find
Right click on a certificate object and select Properties
On the Certificates tab, Select Public Key Certificate. Note the expiration date.

Also see TID 7000075, which states OES SSL certificates expire two years after installation by default.

Fix: ConsoleOne Database error, the local device name is already in use

admin — Mon, 25 Aug 2008 05:03:36 +0000

I was in ConsoleOne 1.3.6e today, trying to connect to a Groupwise 6.5 Domain database and received the following error message:

Database error, the local device name is already in use

I received this message when trying to connect to several domains, but not all of them. I was able to successfully connect to all the domains the previous day.

It did not matter if I tried to connect to the domain by right clicking on the Domain object in Groupwise view, or if I tried to select Tools – GroupWise System Operations – Select Domain, the results were the same error.

I finally found a forum post that suggested mapping a network drive to the server volume that contained the domain directory database. I did this, and was able to connect to ConsoleOne. I didn’t even have to restart C1 to get it to work.

thebackroomtech » ConsoleOne

Fix: Groupwise Login Failed Login Rejected (8219)

Related Posts

Fix for ConsoleOne Error -634 The target server does not have a copy of what the source

Related Posts

Novell TID 3801441 Is Wrong! – How to create a GroupWise user with a specific File ID (FID) for accessing an archive, or restoring a deleted user

Related Posts

Fix for ConsoleOne.exe error – The procedure entry point WpSUDataLength could not be located in the dynamic link library gwenv1.dll

Related Posts

Fix: “Use GroupWise user address as Mail From: for rule generated messages” checkbox in grayed out in ConsoleOne

Related Posts

Creating eDirectory SSL certificates with alternate names to use across round robin DNS load balanced web servers

Related Posts

“Error -618 – The Server has detected an inconsistent database” when trying to view an eDirectory object’s properties in ConsoleOne

Related Posts

Fix: ConsoleOne error “GWIA Admin could not locate file exepath.cfg”

Related Posts

Howto: Find eDirectory SSL certificates and determine when they expire

Related Posts

Fix: ConsoleOne Database error, the local device name is already in use

Related Posts