Tag: Novell

GroupWise Resource Archive – March 2019

Novell Leave a comment
Advansys

The March 2019 release of the free GroupWise Resource Archive, which provides easy research of the NGW Digest email discussions between GroupWise administrators, partners, and consultants, is now available. Use the high speed text search capabilities to discover invaluable guidance within topics ranging from GroupWise technical issues to Micro Focus/Novell business discussions. The GroupWise Resource Archive can be …

+read more

The post GroupWise Resource Archive – March 2019 appeared first on Cool Solutions. Advansys

Related:

GroupWise Resource Archive – February 2019

Novell Leave a comment
Advansys

The February 2019 release of the free GroupWise Resource Archive, which provides easy research of the NGW Digest email discussions between GroupWise administrators, partners, and consultants, is now available. Use the high speed text search capabilities to discover invaluable guidance within topics ranging from GroupWise technical issues to Micro Focus/Novell business discussions. The GroupWise Resource Archive can be …

+read more

The post GroupWise Resource Archive – February 2019 appeared first on Cool Solutions. Advansys

Related:

GroupWise Resource Archive – January 2019

Novell Leave a comment
Advansys

The January 2019 release of the free GroupWise Resource Archive, which provides easy research of the NGW Digest email discussions between GroupWise administrators, partners, and consultants, is now available. Use the high speed text search capabilities to discover invaluable guidance within topics ranging from GroupWise technical issues to Micro Focus/Novell business discussions. The GroupWise Resource Archive can be …

+read more

The post GroupWise Resource Archive – January 2019 appeared first on Cool Solutions. Advansys

Related:

7002943: How to configure GroupWise Clients to send and receive Encrypted and Signed E-Mails using eDirectory User Certificates

Novell Leave a comment
Prior to implement the solution have a look into the Notes: section

1. Create User Certificates

By default, only a user having “Admin” privileges can create User Certificates for users in an eDirectory Tree. So perform following steps as “Admin”.

1.1 Login as Admin using Novell Client from the administration workstation

1.2 Launch ConsoleOne, preferably one from a NetWare server with latest Support Pack (Sys:publicmgmtConsoleOne1.2binConsoleOne.exe)

1.3 Create couple of test user in the desired eDirectory container (Create “Michael Owen” and “John Terry”)

1.4 Create a GroupWise Mailbox for both users and set a GroupWise password for both of them (Use “novell” as password)

1.5 Take properties of the user object “Michael” in NDS View and select Security|Certificates page

1.6 Click on the button Create and create the User Certificate with following parameters as you proceed with the wizard

  • Certificate name: First Name of the User
  • Creation Method: Custom
  • Certificate Authority: Organizational Certificate Authority
  • Key Size: 2048 Bits
  • Key Type: Custom (Once “Custom” is selected enable all Check boxes which get highlighted)
  • E-Mail Address: Specify the E-Mail Address of the user (This field will be automatically filled for a user with mailbox)

1.7 Select the Certificate, click on “Validate” and make sure that Certificate is “Valid”

1.8 Repeat steps 1.5 to 1.7 and create a User certificate for John.

2. Export User Certificates

Even though a user with “Admin” privileges can create User Certificates for regular users, only the corresponding user can export the Certificate with Private Key. So login as test users using iManager from workstations and export User Certificate with Private Key as follows.

2.1 Launch iManager and login as Michael

2.2 Expand the Role “Directory Administration” and select the Task “Modify Object”

2.3 Browse and select the user Object “Michael” and click on “OK”

2.4 Click on “Certificates” tab, select the certificate and export the certificate along with Private Key

2.5 Save the file as “Michael.pfx” into the workstation

2.6 Repeat steps 2.1 to 2.5 by logging in as John and export the certificate for John as “John.pfx



3. Setup an eDirectory LDAP server

Select an eDirectory server with Master or Read/Write replicas of all main partition as an LDAP Server. It’s recommended that the LDAP server should have a replica of Tree [Root] partition for best performance. GroupWise Client by default use query the LDAP server on port 389 (Default non-secure LDAP port). Make sure that LDAP is listening on port 389 as follows

3.1 From Administration workstation, login as Admin using Novell Client and launch ConsoleOne (Launch ConsoleOne from the server to have all necessary snap-ins for LDAP)

3.2 Browse to the server context of the desired LDAP server

3.3 Take properties of the LDAP Group – <Server_Name> Object for the desired LDAP server

3.4 On the General | LDAP Group General tab, disable the Check Box “Require TLS for Simple binds with password”, apply the change and close the properties page.

3.5 Open a server console and reload NLDAP as follows

A. On NetWare

unload nldap

nldap

B. On Linux

nldap -u

nldap -l

3.6 Ensure that LDAP is listening port 389 using Novell Import Convert Export (ICE) utility or other commonly used LDAP tool like LDAP Browser 2.8.2

4. Add the eDirectory LDAP Server in Novell Address Book of GroupWise Client

From here onwards use separate workstations for Michael and John. Wherever it is mentioned to login as John or Michael using Novell Client or GroupWise Client, use the workstation for the user. Using separate workstations helps to differentiate configuration needed for encryption and signing.

4.1 Login as Michael using Novell Client

4.2 Login as Michael using GroupWise Client

4.3 Click on Address Book | Novell LDAP Address Book | Directories

4.4 Click on Add and add an entry called “eDirectory” by providing details of the desired LDAP Server as follows,

  • Server Address: IP Address of the LDAP server
  • Port: 389 (Default non-secure LDAP port)
  • Server Requires log in: Leave unchecked

4.5 Select “eDirectory”, click on the button “Set as Default” and click on “Close”

4.6 Check you are able to query user “John” by typing John’s E-Mail Address in the field “E-Mail Address” and by clicking the button “Retrieve”

4.7 If successful, close the Address Book

Don’t define the LDAP server in the GroupWise Client on John’s workstation at this point.

5. Configure GroupWise Client to search eDirectory for encryption Certificate

GroupWise Client of the sender uses the Public Key of the recipientuser to encrypt the E-Mail. Configure the GroupWise Client of Michael(Sender) to search the eDirectory LDAP server for the Public Key of John as follows.

5.1 Login as Michael using GroupWise Client

5.2 Click on Tools | Options | Send | Security | Advanced Options

5.3 Enable the Check box “Search recipient encryption certificates in the default LDAP directory defined in LDAP Address Book”

5.4 Click on “OK” and close the “Options” Page

6. Install User Certificate with Private Key in GroupWise Client

Perform following steps as John (Not as Michael). Copy over the User Certificate for John to John’s workstation.

6.1 Copy the User Certificate for John, John.Pfx, to John’s workstation

6.2 Login as John using GroupWise Client

6.3 Click on Tools | Options | Certificates

6.4 Click on Import and install the User Certificate for John, ignoring the “Security Warning”

  • Certificate file to import: Point to John.Pfx
  • Enter password: The password specified while exported the certificate with Private Key
  • Security Warning: Ignore the message (Wizard throws out a Security Warning as the certificate is issued by Organizational Certificate Authority (CA) which is not trusted as VeriSign, a popular Public CA)

6.5 Select the Certificate and click on “Set as Default”

6.6 Click on “OK” and close the “Options” page.

Don’t import the user certificate for Michael into the GroupWise Client on Michael’s workstation at this point.

7. Test Encrypted E-Mail

GroupWise Client of Michael will be able to find out the Public Key for John using configurations done as per Steps 4 and 5.

7.1 Send Encrypted E-Mail

7.1.1 Login as Michael using GroupWise Client

7.1.2 Open a “New Mail” and select John using Address Book (Not LDAP Address Book)

7.1.3 On the “Mail To:” window click on the tab Send Options | Security and enable the Check box “Enable for recipients”

7.1.4 Type a few words / a sentence on the Message Body and /or attach a file and send the E-Mail

7.1.5 Switch to the folder “Sent Items” and make sure that you can differentiate the encrypted E-Mail using a “Lock” icon

7.2 Open and verify the Encrypted E-Mail

GroupWise Client of recipient uses the Private Key of the recipient to decrypt incoming encrypted E-Mails. John’s GroupWise Client will be able to open the encrypted E-Mail sentby Michael as the certificate with Private Key for John, is alreadyimported as per step 6.

7.2.1 Login as John using GroupWise Client

7.2.2 Open the encrypted E-Mail Michael sent and make sure that you are able to see contents of the E-Mail, sentence on the Message Body or attached file.

7.2.3 Close the encrypted E-Mail

Trying to send an encrypted reply E-Mail as John will fail as an entry for the eDirectory LDAP server is not yet added in to the Novell LDAP Address Book of John’s GroupWise Client. Similarly, Michael will not be able to view the message body contents or attached file of an encrypted E-Mail from John, until the user certificate with Private Key (Michael.Pfx) is imported into Michael’s GroupWise Client.

8.Test Signed E-Mail

GroupWise client uses the Private Key of the sender to send a Signed E-Mail. GroupWise client of the recipient searches the LDAP Server defined in the LDAP Address Book for the Public Key of the sender to “Validate” the Signature on the incoming Signed E-Mail. Based on configuration done so far, attempt to send Signed E-Mail as Michael will fail as the Private Key for Michael is not yet imported into his GroupWise Client. Try to send a Signed E-Mail as John as the Private Key for John is already imported into GroupWise Client. Proceed as follows.

8.1 Send a Signed E-Mail

8.1.1 Login as John using GroupWise Client

8.1.2 Open a “New Mail” and select Michael using Address Book (Not LDAP Address Book)

8.1.3 On the “Mail To:” window click on the tab Send Options | Security and enable the Check box “Sign Digitally”

8.1.4 Type a few words/sentence on the Message Body and/or attach a file and send the E-Mail

8.1.5 Switch to the folder “Send Items” and make sure that you can differentiate the Signed E-Mail

8.2 Open and Verify the Signed E-Mail

8.2.1 Login as Michael using GroupWise Client

8.2.2 Open the Signed E-Mail John sent and make sure that contents on the message body is visible.

8.2.3 Close the Signed E-Mail

Michael will not be able to send a Signed E-Mail to John as the User Certificate with Private Key for Michael is not yet imported into the GroupWise Client for Michael. Similarly, John will not be able to “Validate” the Signature on Signed E-Mails from Michael, until the eDirectory LDAP server is added to the Novell LDAP Address Book of John’s GroupWise Client.

Related:

GroupWise Resource Archive – November 2018

Novell Leave a comment
Advansys

The November 2018 release of the free GroupWise Resource Archive, which provides easy research of the NGW Digest email discussions between GroupWise administrators, partners, and consultants, is now available. Use the high speed text search capabilities to discover invaluable guidance within topics ranging from GroupWise technical issues to Micro Focus/Novell business discussions. The GroupWise Resource Archive can be …

+read more

The post GroupWise Resource Archive – November 2018 appeared first on Cool Solutions. Advansys

Related:

7022780: Get the most out of Novell Open Enterprise Server 2015

Novell Leave a comment
  • Maximum Cached Sub-directories Per Volume: 1024000

    This is settable by executing “novcifs -k SDIRCACHE=1024000” as root.
  • Maximum Cached Files Per Subdirectory: 102400

    This is settable by executing “novcifs -k DIRCACHE=102400” as root.
  • Maximum Cached Files Per Volume: 2048000

    This is settable by executing “novcifs -k FILECACHE=2048000” as root.

If you however are experiencing inaccessible CIFS shares, CIFS stops listening or communicating, becomes unresponsive or the novell-cifs daemon hangs or other CIFS or novell-cifs daemon related issues, please check TID 7008956 “Troubleshooting and Debugging CIFS on Open Enterprise Server”.

In the lifespan of OES2015 a memory leak was addressed in the NMAS code used for and by the novell-cifsd.

The code on disk is part of the oes2015sp1-July-2017-Scheduled-Maintenance patch, or later.

More details on how to check and when required update the code in the eDirectory can be found in TID 7022690 “ndsd memory leak caused by novell-cifs nmas authentication method on OES2015.1”

NAMCD (LUM):

As several services rely on the Novell Authentication Module for their authentication to the eDirectory it is recommended to tune this so it uses preferably the local server if this has a local replica, or a server on the local subnet that does have a replica of the needed tree partitions.

By default the “preferred-server” is set to the first Novell Open Enterprise Server that was installed in the eDirectory tree, so there is a huge chance this parameter requires adjustment.

To get the current namcd configuration execute as root:

namconfig get

If the preferred-server value does not point to the local ip address (which is preferred even when the server does not have a local replica), or an IP address of a server on the same physical subnet, this can be changed with the following sequence of commands as root:

namconfig set preferred-server=[local ip address (*)]

namconfig -k

namconfig cache_refresh

(*) When in doubt use ‘ndsconfig get’ and use the ip address listed in n4u.server.interfaces without the @524.

Alternatively, if the server does not have a local replica, it is also possible to add one or a couple alternative LDAP servers.

Adding a single alternative LDAP server is possible by executing this command as root:

namconfig set alternative-ldap-server-list=[ds-server01]

Adding more than one alternative LDAP server is possible using a comma separated list and can be accomplished by executing the following command as root:

namconfig set alternative-ldap-server-list=[ds-server01],[ds-server02],[ds-server03]

The usage of alternative LDAP servers for LUM can also be used to make LUM more scalable.

It is also recommended to turn persistent search off and cache-only on.

This can be accomplished by executing these commands as root:

namconfig set persistent-search=no

namconfig set cache-only=yes


As the namconfig cache_refresh includes a restart of the namcd there is no need to restart this daemon to enable these changes.

For the other changes and tunings to be enabled, it is recommended to restart the namcd.

NSS.

Although it is required to tune Novell Storage Services to the requirements of the environment it is being used, these are some tunings worth considering:

– Increase the NSS IDCacheSize to 128K, this can be accomplished by executing, as root:

nsscon /idcachesize=131072

– Disable the Access Time by executing the following line as root:

nsscon /noatime=[volume name]

– From OES2SP2 onwards the Unplugalways parameter has a default value set to “off”. If this is not the case, disable it by executing as root:

nsscon /nounplugalways

More details can be found in “UnplugAlways Command for the Read Queue” in “Cache Management Commands” of the “NSS Commands” section in the OES2015 Documentation.


In order to make these tunings persistent they must be added (as by default they are not there) to the /etc/opt/novell/nss/nssstart.cfg, though make sure to make no typos in this file, as they can cause novell-nss to fail to start.

Make sure that all unmarked entries in this file start with “/” and not “nss /“.

Using nssmu, launched as root, increase the “read ahead blocks” for all nss volumes from the default value of 16 to 64.

If over time this appears to be insufficient, this can be increased to 128. It is not really recommended to go beyond this value, as it may have a negative impact on the performance.

This change is activated “on the fly”, and does not require a server restart.
Furter information regarding tuning NSS performance can be found in “Tuning NSS Performance” in the “NSS File System Administration Guide for Linux” of the OES2015 Documentation.

During the lifespan of a NSS Volume it is recommended to preserve at least 10% to 20% free space. Available purgable disks pace does not equal to true free disk space that is available.

Once a volume drops below these thresholds and there is insufficient true free disk space is available to the system to write data, a background process starts calculating what is the oldest deleted data that can be purged for the system in order to make space available for the new data to be written to disk..When there are large amounts of purgable data, nearly no true free space and large amounts of data is written this calculation process becomes a thread that will cause continuous I/O, performance degradation and other unwanted phenomena up to data corruption or loss.

For this reason it is recommended for NSS volumes hosting services with a high usage of temporary files to mark either the folders used for temporary storage or the volume as “purge immediate”, basically disabling salvage for those directories or the volume.

When a volume passes these thresholds it is recommended to either expand the pool and volume, delete obsolete data but a temporary measure may be to manually purge the volume.

This can be accomplished by executing the following command as root:

ncpcon purge volume [volume name]

However, as storage areas have become greater over time, grown into the terabytes (TB) keeping 20% free space might be a bit too much.

In case the NSS Pool size is in the TBs or larger, it might be worthwhile to consider lowering the PoolHighWaterMark and PoolLowWaterMark that is used for these large NSS Pools.

More details on this can be found in the “Salvage and Purge Commands” of the OES2015 documentation

After adjusting the PoolHighWaterMark and PoolLowWaterMark the behavior of the server will be the same when dropping below the set WaterMarks.

SMS (tsafs / backup)

In case you are suffering from slow performing back-up, or regressing back-up speed, the documentation for optimizing sms on OES2015 can be found in “Optimizing SMS” in the “Storage Management Services Administration Guide for Linux” of the OES2015 Documentation.

NCS:

In a cluster environment, where a single OES2015 server might be hosting several NSS, NSSforAD, NCP and CIFS volumes at once, it is recommended to use lower cache values compared to a standalone OES2015 server.

The OES2015 cluster node must be able to handle the cache and memory requests when it is hosting all cluster resources at once.

All the previous steps should also address most issues seen with OES2015 servers running Novell Cluster Services and their cluster-enabled resources.

Non the less, if you are suffering from random split brains, without a physical reason (LAN or SAN outage), it would be advisable to investigate if there are time-jumps (back and or forward) caused by the CPU. Clock Jumps can occur on physical and virtual CPU’s and is not restricted to either of those.

In some cases where Novell Cluster Services are not starting up properly at boot-up, it is recommended to alter the /etc/sysconfig/boot so it reads RUN_PARALLEL=”no”.

This to allow the Novell services to start in their proper sequence and is the default for OES2015.




PKI (Certificate Server):

During the installation of any OES server, a couple default Server Certificates are generated.

These are by default valid for 2 years. After this period, when the certificates expire the server and all servers that use the server as LDAP source will no longer be able to access the required eDirectory information and all services that rely on it will fail.

Therefor it is recommended to validate the Default Server Certificates when some or all services of a particular server fails as one of the troubleshooting steps. If the failing server is using a different server as preferred_server, or LDAP source, that particular server’s Default Certificate Material should be checked too.

The LDAP servers that the server might be using are listed under /ets/sysconfig/novell/ldap_servers/ though it is recommended to also check each service to determine which LDAP server it is using, as they may differ.

A method of validating the Default Certificates of a server is via iManager.

This can be accomplished under the “Novell Certificate Access”, the “Server Certificates” task.

If one or more certificates is deemed invalid, the next step would be to repair these.

This task can be accomplished under “Novell Certificate Server”, the “Repair Default Certificates” task.

More details on this can be found in TID 7000075 “SSL Certificates expire after two years, affecting OES Services”


In case the LDAP server being used is a Novell NetWare server, these tasks can also be accomplished using the pkidiag.nlm


After the Certificates were replaced or repaired, it is recommended to at least restart the ndsd (rcndsd restart) so the server is using the new certificate for it’s LDAPS communication and run a namconfig -k to update the certificate that namcd is using.


A more sustainable option might be to enable “Self-Provisioning” for the Certificate Authority (CA) of the tree.

This feature is described here in the Novell Documentation.

Enabling this for the CA of the tree, this feature is enabled for all servers in the tree that use this CA.

As soon as the server or it’s ndsd is restarted it will be aware that “Server Self Provisioning” is enabled.

With this feature enabled, the certificates that are expired or about to be expired are extended automatically when executing either:

ndstrace

unload pkiserver

load pkiserver

or

rcndsd restart


Anti-Virus scanners:

When an Anti-Virus suite is installed, try to avoid the usage of “on access” scanning, as this can create a severe overhead.

The Anti-Virus suite, running either locally or remotely, should be excluded from scanning system crucial directories like the ._NETWARE of all NCP exported filesystems (both NSS and POSIX), /_admin and the Linux System directories.

In case Novell Cluster services is installed, /admin should also be excluded from being scanned by the anti-virus.

In case Novell GroupWise is installed, all repository and queue directories should be excluded from being scanned by the anti-virus as well. Novell GroupWise stores it’s information in an encrypted way, so scanning the physical files stored on disk is unnecessary and can even cause severe problems like file locking or even corruption.

There are several Anti-Virus suites that can scan inside the Novell GroupWise mail storage and / or incoming e-mail.

Related:

7018164: Enabling eDirectory’s event caching: Journal Event Caching vs. XDAS/CEF caching

Novell Leave a comment
eDirectory has two event caching mechanisms. Each is separate and helps solve one of the challenges outlined above.



Journal Event Cache

Description: this cache applies to ALL journal events: ndstrace, XDAS, NAudit, IDM events, etc. A location on disk can be set to store cached events. This location will be used rather than memory when the number being created becomes greater than the number that can be processed. This cache resides in the NDSD event system and is at a lower layer than the XDAS cache.

Pros: this helps reduce NDSD’s memory footprint by storing those events not yet processed to disk instead.

Cons: consumes additional disk space but compression lowers this requirement. It can also be slower to process the events since they must first be written to then retrieved from disk rather than memory.

Configuration: this cache’s settings are controlled via environment variables set in the ndsd script.

– NDSD_EVENT_DISK_CACHE

Enables the Journal Event Cache.



– NDSD_EVENT_DISK_CACHE_DIR

Sets the cache directory. Optional, default for Linux is /var/opt/novell/eDirectory/data/ and the dib directory for Windows.
As these are environment variables these are set in the following locations:
init.d: /opt/novell/eDirectory/sbin/pre_ndsd_start
systemd: /etc/opt/novell/eDirectory/conf/env
Example
NDSD_EVENT_DISK_CACHE=1
EXPORT NDSD_EVENT_DISK_CACHE

– There is no Journal Event cache setting for specifying the size. The Journal cache will use file sizes of 4MB or less while implementing its own compression upon them.

XDAS Cache

Description: The cache is implemented in the xadauditds layer and is ONLY used when:

1. XDAS specific events are ready to be sent to a remote auditing server.

AND

2. The remote server cannot be reached.

Pros: Prevents the loss of audit event information when a remote audit server cannot be contacted. This cache is only used when required. The events are released once the remote server’s connection is reestablished.

Cons: other than some additional disk space used, none since it is only used if there is a problem.

Configuration: this cache’s settings are controlled via variables set in the xdasconfig.properties file.

– log4j.appender.S.CacheEnabled

Enables the XDAS Cache for storing XDAS events locally.

– log4j.appender.S.CacheDir

Optionally specifies the directory to use (/var/opt/novell/eDirectory)

– log4j.appender.S.CacheMaxFileSize

Specifies the maximum file size. Values can be from 50MB to 4GB. The default is 512MB.

These cachemethodscan be used together. Consider the following scenario.

a. An XDAS audit event for a login is thrown but its reporting to the consumer is delayed behind other earlier events. The event gets written to the Journal Event Cache.

b. The Journal thread comes along and releases this event from the Journal Cache.

c. The configured remote audit server cannot be contacted. The event goes into the XDAS Cache.

d. The remote server is brought online again. The event is released from the XDAS cache and sent to a remote syslog appender.

More information can be found in the eDirectory Admin Guide found here: https://www.netiq.com/documentation/

CEF Cache

As with XDAS this cache is implemented in the audit layer and is ONLY used when:
1. CEF specific events are ready to be sent to a remote auditing server.

AND

2. The remote server cannot be reached.
The auditlogconfig.properties file should be modified to change the log4j.appender.S.CacheEnabled property to a value of ‘yes’. It is also suggested to specify a value for ‘log4j.appender.S.CacheDir’. Setting this as well as eDirectory
s RFL directory to a a drive other than that occupied by the dib can both boost performance.

More information can be found in eDirectory’s Admin Guide under ‘Auditing with CEF’ – ‘Enabling CEF event caching’.

Related:

7023501: Mobility Service error: Cannot connect to GroupWise administration to veify license.

Novell Leave a comment
1. Stop GMS service and go into /var/lib/datasync/mobility directory -> delete from there gwadmin_ca.pem file.

2. On a GW server running your primary, stop gwadminservice.

3. Go into /opt/Novell/GroupWise/certificates. There will be a system GUID directory -> rename it into old or delete it.

4. From a terminal, generate new system directory by:

gwadminutil ca -d /<path to primary> -g -f

5. Start gwadminservice again.

6. Start gwadminconsole and connect to the primary domain -> MTA object -> SSL Settings tab, here delete and regenerate system certificates if you were using self-signed system ones before.

7. On a GMS server mount the GMS ISO image again that you were using for the installation of GMS recently and re-run the install again. That shall go over without any complains now.

Related:

GroupWise Resource Archive – October 2018

Novell Leave a comment
Advansys

Apologies for missing September, the good news is the October 2018 release of the free GroupWise Resource Archive, which provides easy research of the NGW Digest email discussions between GroupWise administrators, partners, and consultants, is now available. Use the high speed text search capabilities to discover invaluable guidance within topics ranging from GroupWise technical issues to Micro Focus/Novell business …

+read more

The post GroupWise Resource Archive – October 2018 appeared first on Cool Solutions. Advansys

Related:

7022802: Inventory Scan Fails when USB Flash Drive is connected

Novell Leave a comment
  • Inventory scan generates excessive warning messages in ZCC
  • USB Flash Drive is connected during inventory scan

The following files may be found in %ZENWORKS_HOME%workinventory :

  • zenBackup.xml
  • zenDeltaBackup.xml

The following message may be seen in ZCC:

Novell.ZENworks.InventoryManager RunFieldApplications problem: RunFAProblemUnexpectedException (The file ‘C:Program Files (x86)NovellZENworksworkinventoryzenBackup.xml’ already exists.)

The following or similar may be seen in zmd-messages.log:

[ZenworksWindowsService] [98] [rlm] [InventoryManager] [] [RunFAProblemUnexpectedException: (System.IO.IOException: The file ‘C:Program Files (x86)NovellZENworksworkinventoryzenBackup.xml’ already exists.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)

at Novell.Zenworks.InventoryManager.UMXLatorZENHelper.backUpWifs()

at Novell.Zenworks.InventoryManager.InventoryScan.RunScan(ScanType type, String eventid))] [] [] [] [ZENworks Agent]

[ZenworksWindowsService] [98] [rlm] [InventoryManager] [InventoryManager.RunFAProblem] [Novell.ZENworks.InventoryManager RunFieldApplications problem: RunFAProblemUnexpectedException (The file ‘C:Program Files (x86)NovellZENworksworkinventoryzenBackup.xml’ already exists.)] [] [] [] [ZENworks Agent]

[ZenworksWindowsService] [98] [] [ZenCache] [] [(Thread 98) PutObject(Inventory.LastScanEnd, UserContext{_LocalId=none; _RemoteId=(Public)}) called] [] [] [] [ZENworks Agent]

The following or similar may also be seen in zmd-messages.log:

[ZenworksWindowsService] [96] [] [InventoryManager] [] [WifAccess exceptionSystem.InvalidOperationException: There is an error in XML document (203, 32). —> System.Xml.XmlException: ”, hexadecimal value 0x03, is an invalid character. Line 203, position 32.

at System.Xml.XmlTextReaderImpl.Throw(Exception e)

…

[ZenworksWindowsService] [96] [] [InventoryManager] [] [Exception in GetHtmlFromWIF : ”, hexadecimal value 0x03, is an invalid character. Line 204, position 32.]

…

[ZenworksWindowsService] [78] [] [InventoryManager] [] [Exception while trying to compare if previous scan was hardware only scan : There is an error in XML document (203, 32).]

[ZenworksWindowsService] [78] [] [InventoryManager] [] [Exception while trying to compare if previous scan was software only scan : There is an error in XML document (203, 32).]

…

[ZenworksWindowsService] [78] [] [InventoryManager] [Failed to read in provided path :C:Program Files (x86)NovellZENworksworkinventory384d956bf1b4474c84ee2660ee030d37-last.xml] [xml]

[ZenworksWindowsService] [78] [] [InventoryManager] [] [There is an error in XML document (203, 32).]

[ZenworksWindowsService] [78] [] [InventoryManager] [Failed to read in provided path :C:Program Files (x86)NovellZENworksworkinventoryzenBackup.xml] [xml]

[ZenworksWindowsService] [78] [] [InventoryManager] [] [There is an error in XML document (203, 32).]

[ZenworksWindowsService] [78] [] [InventoryManager] [] [Exception : While dumping Usage into Wif : The process cannot access the file ‘C:Program Files (x86)NovellZENworksworkinventoryzenBackup.xml’ because it is being used by another process.]

The following or similar may be seen in %ZENWORKS_HOME%workinventory<GUID>-full.xml file:

<SerialNumber>&#x3;C</SerialNumber>

Related: