DCOM Help

General Information

This Help File was designed to give the user of component's commmunication through DCOM (specially OPC users) an idea on possible settings in an industrial environment. This Help File just showes possible settings of DCOM security that will make the system running. If the manufacturers or vendors of OPC products provide their own manuals, this manuals should be used instead of this Help File.

Important Notes

Before changing any settings of DCOM security, a system recovery procedure should be prepared. All settings described in this documentation should be tested in a laboratory environment, before changing machines in production.
  • Save system partition including Windows Registry (Image Software)
  • Only local administrators are allowed to change DCOM settings
  • Test all settings in a laboratory environment before changing the production machine


Overview

This documentation deals with COM components that should comunicate with each other. There are tree different types of COM -Servers known, depending on their operational environment.

  • INPROC- Server
    The COM-Server runs in the memory area of the Client, the Server is a DLL and runs local on the same machine and in the same process.
  • LOCAL-Server
    The COM Server runs in it's own memory area, the Server is a EXE and runs local on the same machine, but in it's own process
  • REMOTE-Server
    The COM Server runs in it's own memory area, the Server is a EXE and runs remotely on a different machine and (of course) in it's own process as the Client

The communication between Client and Server process follows the rules of COM. Whenever the Client is located on one machine and the Server on an other, DCOM (Distributed COM) comes into place. The function calls between Client and Server process are checked for correct security by the operating system. The security settings for DCOM have NOTHING to do with sharing folders between two machinen or network shares across a network. When it comes to DCOM-Security we talk about "inter process communication", in other words: the right to start or access a certain component.

To keep configuration simple it is assumed that two machines have the same operating system installed, are both in the same Workgroup and have the same user accounts (same person/PWD actually logged on). On the Server Machine an OPC Server is located and on the Client Machine an OPC Client was installed.


Network Configuration

Depending on the configuration of the network different identification of Users will be performed by the operating system. Considerations regarding this issues are divided into the following topics.

  • Workgroup
  • Domain
  • Mixed Domain and Workgroup


Workgroup

For proper DCOM security settings it is essential to identify the configuration of the Client and the Server machine. If both machines are members of the same workgroup there will be no central point for user authentification. This means that every single machine must have all information on all users that should be able to remote access this node (local identification). The administrative effort will increase imensely when adding new users.

  • Workgroup
    The Client and Server Machine should be member of the same Workgroup.
  • Users Accounts
    As authentification is performed locally on every single machine, the User Accounts (Name and PWD) should be identical on the Client and the Server Machine.
  • Operation System
    The Operation System on the Client and the Server Machine should be from the same family (all NT, all 2K or all XP). When doing "mixed configuration" certain (OS specific) settings have to be taken into account.

To keep configuration simple it is assumed that two machines have the same operating system installed, are both in the same Workgroup and have the same user accounts (same person/PWD actually logged on). On the Server Machine an OPC Server is located and on the Client Machine an OPC Client was installed.


Domain

Domain Controller

For proper DCOM security settings it is essential to identify the configuration of the Client and the Server machine. If both machines are members of the same domain there will be one central point for user authentification. If both machines are in different domains, these donains must trust eachother. The administrative effort will decreases because new users will only be added to the domain.

  • Domain
    The Client and Server Machine should be member of the same Domain. Different domains must should be trust eachother.
  • Users Accounts
    Authentification is performed on the domain machine, the User Accounts (Name and PWD) or groups are used in the DCOM settings of the Client and the Server Machine.
  • Operation System
    The Operation System on the Client and the Server Machine should be from the same family (all NT, all 2K or all XP). When doing "mixed configuration" certain (OS specific) settings have to be taken into account.

To keep configuration simple it is assumed that two machines have the same operating system installed, are both in the same Domain and have different user accounts logged on. The different users are members of one User Group. This for this User Group access is granted in the DCOM settings of the Client and the Server Machine.

Note: In a mixed configuration (e.g. Server Machine in a Domain and Client Machine in a Workgroup) the so called doubble identification should be done. This means to add User Accounts to the Workgroup Machine which are identically (Name and PWD) the same as the User Accounts on the Domain. By this function calls to the Workgroup Machine can (locally) be identified and granted without "asking" the Domain Controller.


Mixed

Mixed Domain and Workgroup

For proper DCOM security settings it is essential to identify the configuration of the Client and the Server machine. If only one machine (e.g. the Client) is members of a domain there will be no central point for user authentification. If the other machine is not in that domain, it must locally authentificate the user. The administrative effort will increases because new users will must be added to the domain and all machines in the workgroup.

  • Mixed Domain (Client) / Workgroup (Server)
    The Client Machine is member of a Domain and the Server Machine is membber of a Workgroup. On ther Servermachine a local user account must exist, that is identical with the Domain account used on the Client Machine.
  • Users Accounts
    Clientside authentification is performed on the domain machine, the User Accounts (Name and PWD) or groups used in the DCOM settings of the Server Machine must be identical (double identification).
  • Operation System
    The Operation System on the Client and the Server Machine should be from the same family (all NT, all 2K or all XP). When doing "mixed configuration" certain (OS specific) settings have to be taken into account.

To keep configuration simple it is assumed that two machines have the same operating system installed, are both in the same Domain and have different user accounts logged on. The different users are members of one User Group. This for this User Group access is granted in the DCOM settings of the Client and the Server Machine.

Note: In a mixed configuration (e.g. Client Machine in a Domain and Server Machine in a Workgroup) the so called doubble identification should be done. This means to add User Accounts to the Workgroup Machine which are identically (Name and PWD) the same as the User Accounts on the Domain. By this function calls to the Workgroup Machine can (locally) be identified and granted without "asking" the Domain Controller.


Operating System

Depending on the operating system different identification of Users will be performed. Considerations regarding this issues are described in the following pages.

  • Windows 2000
  • Windows XP + SP2
  • Windows 2003


Windows 2000

This section describes the required settings for Windows 2000 operating system only.

On Windows 2000 SP 1 operating system there are some known bugs related to proper callback operation. DCOM servers installed on a Win2k SP1 machine sporadically stop sending callbacks (e.g. OnDataChange) after days or weeks. The error code 0x80010108 (RPC_E_DISCONNECTED) is returned by the DCOM Server when trying to fire a callback. All other calls form the Client to the Server still work fine.

There are three ways to overcome this problem:

  • release the callback object and subscribe again (recreate the callback object)
  • install COM + Rollup Package 18.1 (Post Service Pack 2)
  • install Service Pack 3 (or higher) for Windows 2000


Windows XP

This section describes the required settings for Windows XP operating system only.

The default installation for XP forces remote users to authenicate as Guest. This means that DCOM clients cannot connect to a server running on an XP machine unless the Guest account is enabled and has enough rights to launch the server. On the other hand when a DCOM server fires a callback to a remote Client installed on an XP machine, the authentification will be "changed back" to the Guest account (which is mostly disabled by default). Thus, the callback (e.g. OnDataChange) will never get through to the Client.

Classic:To force an XP machine to "behave" like a Windows 2000 computer the Network Access must be changed. Open the Security Options dialog with: START >> Control Panel >> Administrative Tools >> Local Security Policy >> Local Policies >> Security Options . Find the following entry: Network access: Sharing and security model for local accounts
and change this setting to: Classic - users authenticate as themselves

Note: in a mixed configuration (e.g. Client installed on XP and Server installed on Windows 2k) the XP machine automatically "changes" to the classic Win2k bevavior when lauching and accessing the DCOM Server, but there will be no callbacks comming through unless the Client-side Access Permissions are granted.

SP2: with Service Pack 2 (SP2) Mircrosoft introduced machine-wide access limitation for COM servers. Launch/Activation and Access Permissions will now be additionally checked for all COM servers on the machine. This AccessCheck (ACL) is done prior to all other (individual) checks and even overwrites the settings done by the server itself (during CoInitializeSecurity call). Thus, an administrator can easily grant or deny permission to all COM servers on the machine without clicking through the individual security settings.

Firewall: with Service Pack 2 (SP2) Mircrosoft introduced the Windows Firewall. During all setting the Firewall should be switched off. After testing correct function of remote access (connect and callback) the firewall can be turned on again. The TCP Port 135 for the use of DCOM must be opened (added to the exception list). The OPC Enum and each server that should be accessd must be added to the exception list of the firewall.


Windows 2003

This section describes the required settings for Windows 2003 operating system only.

The default installation for 2003 forces remote users to authenicate as Guest. This means that DCOM clients cannot connect to a server running on an 2003 machine unless the Guest account is enabled and has enough rights to launch the server. On the other hand when a DCOM server fires a callback to a remote Client installed on an 2003 machine, the authentification will be "changed back" to the Guest account (which is mostly disabled by default). Thus, the callback (e.g. OnDataChange) will never get through to the Client.

Classic:To force an 2003 machine to "behave" like a Windows 2000 computer the Network Access must be changed. Open the Security Options dialog with: START >> Control Panel >> Administrative Tools >> Local Security Policy >> Local Policies >> Security Options . Find the following entry: Network access: Sharing and security model for local accounts
and change this setting to: Classic - users authenticate as themselves

Note: in a mixed configuration (e.g. Client installed on 2003 and Server installed on Windows 2k) the 2003 machine automatically "changes" to the classic Win2k bevavior when lauching and accessing the DCOM Server, but there will be no callbacks comming through unless the Client-side Access Permissions are granted.


Client Machine

This section describes the required settings of the Client side only. The Client side is the machine (computer) on which the OPC Client application is running. Normally on this machine no OPC Server is installed. However, on some systems OPC Clients and Servers are installed on the same node, thus the settings of the Server side installation must be performed also.

Depending on the operating system running on the Client machine the apearance of the dialog boxes is different. Generally the same settings must be performed. However, some "operating system specific" settings must be done to get the DCOM security runing.

  • Windows NT 4 SP 6a
  • Windows 2000 SP 3
  • Windows XP (SP 2)
  • Windows Server 2003 SP 1


Firewall Client Machine

Open Firewall Configuration

Only local administrators are allowed to open and change the Windows XP + SP2 Firewall settings.

Note: During all DCOM configuration the Windows Firewall should be switched off completely. After Client- and Server-Side DCOM configuration and testing of all functions including behavior after reboot the firewall settings (activation) should be done.

Use START >> Settings >> Control Panel >> Windows Firewall to start the Firewall configuration dialog.

Select the Exceptions tab and click Add Program to add the applications that should pass the firewall, than click Add Port to add Port 135 which is used for DCOM.

Exceptions on Client Machine


Firewall Settings on Client Machine

Firewall Configuration on Client

This section discribes exceptions to the Windows Firewall that must be set on the Client Machine.

Note: when opening the Windows Firewall the computer is open for possible attacks, especially when opening Port 135 for DCOM. For each entry in the exception list of the Windows Firewall the exception can be limited to a certain machine (IP-Address). Use the Change Scope button when editing the firewall's exception list. This is not realy save, but makes it harder to attack.

Select the Exceptions tab and click Add Program to add the OPC Client application to the firewall's exception list.

Select the Exceptions tab and click Add Program to add the Miscrosoft Management Console application to the firewall's exception list.

Select the Exceptions tab and click Add Port to add Port 135 to the firewall's exception list.

The firewall's exception list should at least have the following entries.

Known Bugs: Changes to the exception list of the Windows Firewall sometimes are not applied directly. Switch the Firewall on and off to get the changes take effect. Make sure that none of the applications is in use when doing so.


ACL on Client Machine

Open Access Control Limits Configuration

Only local administrators are allowed to open and change the ACL settings.

Use START >> RUN >> dcomcnfg.exe to start the DCOM configuration dialog.

Browse down to Console Root >> Component Services >> Computers and right click on My Computer than select Properties to open the DCOM configuration dialog.

ACL on Client Machine


ACL on Client Machine

ACL Configuration on Client Machine

Only local administrators are allowed to open and change the ACL settings.

Note: Changes to the Access Control Limits take effect for all COM Objects on the machine. These settings even overwrite the settings made by the COM Object itself (CoInitializeSecurity). The Limits can be seen as a filter prior to all other (individual) settings of a COM Object. Only if a call is granted permission in the ACL it will be passed to the individual DCOM security settings of the particular COM Object.

Select the COM Security tab to edit the access permission limits for all COM Objects on this machine.

By default the limits for Access Permission are granted locally to Anonymous and Everyone only.

For changing the Access Permission click the Edit Limits button and add the security context in which the OPC Server is started (when sending OnDataChange callbacks the OPC Server needs access permission to reach the Client). Grant access permission for (at least) remote access.


DCOM on Client Machine

Open DCOM Configuration

Only local administrators are allowed to open and change the DCOM security.

Use START >> RUN >> dcomcnfg.exe to start the DCOM configuration dialog.

Browse down to Console Root >> Component Services >> Computers and right click on My Computer than select Properties to open the DCOM configuration dialog.


General Tab

On the General Tab no changes have to be done. The default settings will be correct for OPC Client side security settings.


Options Tab

On the Options Tab no changes have to be done. The default settings will be correct for OPC Client side security settings.


Default Protocols Tab

On the Default Protocols Tab the Connection-oriented TCP/IP protocol should be moved to the top position. This setting forces the use of TCP/IP for DCOM connections. All other protocols can be removed if the are not used with DCOM. The timeout will be reduced if DCOM tries to connect only on TCP/IP connections.


Default Properties Tab

On the Default Properties Tab the Enable Distributed COM on this computer must be checked. The Authentification Level and the Impersonation Level are set to Connect and Identify by default.

If the client machine runs in a Workgroup the level remains to default settings

  • Authentification Level = Connect (only Windows NT/2k = None)
  • Impersonation Level = Identify (only Windows NT/2k = Anonymous)
If the client machine runs in a Domain the level remains to default settings
  • Authentification Level = Connect
  • Impersonation Level = Identify
If the client machine runs in a mixed configuration (e.g. the Server machine in a Workgroup and the Client machine in a Domain) the level should remain unchanged. The machine being part of the Workgroup must be able to identify the security context without "asking" the Domain. Therefore the machine must "know" the users (they must have a local Login).
  • Authentification Level = Connect
  • Impersonation Level = Identify

Note: not all possible combinations of setting these two levels make sense.

Known Bugs: on Windows 2000 operating systems the Network Configuration Icon disapears when setting DCOM security levels to None and Anonymous. The network still works but the IP-Address of the NIC can not be changed anymore. Change temporarely to default settings to change IP Address or use None and Delegate.


Default COM Security Tab

On the Default COM Security Tab the Access- and Launch permission for all COM-Objects can be changed. As the OPC Client is nothing else than a COM Client, the security setings should be changed to grant access to the Client application. Specially when the OPC Server sends callbacks (e.g. OnDataChange) to the OPC Client the server's process must have access permission on the Client.

The Default Access Permission should be granted for

  • Administrators
  • Interactive User
  • System
  • Network
  • "OPC Server's Security Context"

The Default Launch Permission should not be changed on the Client machine.


MSDTC Tab

On the MSDTC Tab no changes have to be done. The default settings will be correct for OPC Client side security settings.


Server Machine

This section describes the required settings of the Server side only. The Server side is the machine (computer) on which the OPC Server application is running. Normally on this machine no OPC Client is installed. However, on some systems OPC Clients and Servers are installed on the same node, thus the settings of the Client side installation must be performed also.

Depending on the operating system running on the Server machine the apearance of the dialog boxes is different. Generally the same settings must be performed. However, some "operating system specific" settings must be done to get the DCOM security runing.

  • Windows NT 4 SP 6a
  • Windows 2000 SP 3
  • Windows XP SP 1
  • Windows Server 2003 SP 1


Firewall Server Machine

Open Firewall Configuration

Only local administrators are allowed to open and change the Windows XP + SP2 Firewall settings.

Note: During all DCOM configuration the Windows Firewall should be switched off completely. After Client- and Server-Side DCOM configuration and testing of all functions including behavior after reboot the firewall settings (activation) should be done.

Use START >> Settings >> Control Panel >> Windows Firewall to start the Firewall configuration dialog.

Select the Exceptions tab and click Add Program to add the applications that should pass the firewall, than click Add Port to add Port 135 which is used for DCOM.

Exceptions on Server Machine


Firewall Settings on Server Machine

Firewall Configuration on Server

This section discribes exceptions to the Windows Firewall that must be set on the Server Machine.

Note: when opening the Windows Firewall the computer is open for possible attacks, especially when opening Port 135 for DCOM. For each entry in the exception list of the Windows Firewall the exception can be limited to a certain machine (IP-Address). Use the Change Scope button when editing the firewall's exception list. This is not realy save, but makes it harder to attack.

Select the Exceptions tab and click Add Program to add the OPC Server application to the firewall's exception list.

Select the Exceptions tab and click Add Program to add the OPC Enum application to the firewall's exception list.

Select the Exceptions tab and click Add Program to add the Miscrosoft Management Console application to the firewall's exception list.

Select the Exceptions tab and click Add Port to add Port 135 to the firewall's exception list.

The firewall's exception list should at least have the following entries.

Known Bugs: Changes to the exception list of the Windows Firewall sometimes are not applied directly. Switch the Firewall on and off to get the changes take effect. Make sure that none of the applications is in use when doing so.


ACL on Server Machine

Open Access Control Limits Configuration

Only local administrators are allowed to open and change the ACL settings.

Use START >> RUN >> dcomcnfg.exe to start the DCOM configuration dialog.

Browse down to Console Root >> Component Services >> Computers and right click on My Computer than select Properties to open the DCOM configuration dialog.

ACL on Server Machine


ACL on Client Machine

ACL Configuration on Server Machine

Only local administrators are allowed to open and change the ACL settings.

Note: Changes to the Access Control Limits take effect for all COM Objects on the machine. These settings even overwrite the settings made by the COM Object itself (CoInitializeSecurity). The limits can be seen as a filter prior to all other (individual) settings of a COM Object. Only if a call is granted permission in the ACL it will be passed to the individual DCOM security settings of the particular COM Object.

Select the COM Security tab to edit the access permission limits for all COM Objects on this machine.

By default the limits for Access Permission are granted locally to Anonymous and Everyone only.

For changing the Access Permission click the Edit Limits button and add the security context in which the OPC Client is started (the OPC Client needs access permission to reach the Server). Grant access permission for (at least) remote access.

By default the limits for Launch Permission are granted to Administrators (local and remote) and to Everyone (locally only).

For changing the Launch Permission click the Edit Limits button and add the security context in which the OPC Client is started (the OPC Client needs lauch/activation permission to start the Server). Grant launch permission for (at least) remote access.


Server Machine

Open DCOM Configuration

Only local administrators are allowed to open and change the DCOM security.

Use START >> RUN >> dcomcnfg.exe to start the DCOM configuration dialog.

Browse down to Console Root >> Component Services >> Computers >> My Computer >> DCOM Config to display all DCOM server applications. Select the appropriate Server and right click on it. Select the Properties dialog to change the DCOM security for this specific DCOM Server only.


General Tab

General Tab (server specific)

On the server specific General Tab no changes have to be done. The default settings will be correct for OPC Server side security settings. The Authentification Level set to Default will overtake the settings from the Default Properties Tab valid for all COM Objects on this machine (Connect by default).


Location Tab

Location Tab (server specific)

On the server specific Location Tab no changes have to be done. The default settings will be correct for OPC Server side security settings.


Security Tab

Security Tab (server specific)

On the server specific Security Tab the Access- and Launch permission for this specific COM-Server can be changed. As the OPC Server is nothing else than a COM Server, the security setings should be changed to grant access and lauch permission to the Server application.

The Server Specific Access Permission should be granted for

  • Administrators
  • Interactive User
  • System
  • Network
  • "OPC Client's Security Context"

The Server Specific Launch Permission should be granted for

  • Administrators
  • Interactive User
  • System
  • Network
  • "OPC Client's Security Context"

The Server Specific Configuration Permission should not be changed on the Server machine.


Endpoints Tab

Endpoints Tab (server specific)

On the server specific Endpoints Tab the default setting should remain. In the Default Protocols Tab for all COM-Objects Connection-oriented TCP/IP protocol should be moved to the top position.


Identity Tab

Identity Tab (server specific)

On the server specific Identity Tab normally no changes have to be done. By default the Interactive User will be selected. This means that the server will be lauched with the security context of the interactive user (the user that is actually logged on). As this security context changes if somebody else is logged on, in most cases a specific person should be selected i.e even if nobody is logged on to the machine (after reboot) the server can be launched having always the same security context.

The prefered setting should be the third selection.

  • The interactive user = default
    The interactive user depends on the person that is logged on, thus it can be different each time and only exists if somebody is logged on.
  • The launching user = should NEVER be used
    The launching user will have the security context of the Client application (the OPC Client lauches/connects the OPC Server). When having different Clients in the network, several instances of the Server will be lauched having different security context each.
  • This user = Server will overtake the security context of this person
    By selecting This user it will be guaranteed that always the same person's security context is used when the server is started. On the Client side only for this person the Access Permission must be granted.


Permission

Within DCOM Security the launch permission is described as the right to start (launch) an application. As an OPC Server will be started (launched) by the Client application (CreateInstance) the launch permission for the OPC Server application must be granted for the Security Context in which the OPC Client is running. The Security Context of the Client may be different depending on the user actually logged in and double clicked (started) the Client.

The access permission is described as the right to access (communicate to) an application. As an OPC Client will call functions on the OPC Server Object the Security Context of the Client must be known by the Server. When sending callbacks to the Client (asynchronous functions or DataChange) the Client must grant access permission to the OPC Server.

  • Access Permission
  • Launch Permission
  • Select Users


Access Permission

For granting access permission (accessing the application) to a certain user the Edit... button must be clicked opening the following dialog.

For selecting users click the Add.. button:

Selecting Users


Launch Permission

For granting launch permission (starting the application) to a certain user the Edit... button must be clicked opening the following dialog.

For selecting users click the Add.. button:

Selecting Users


Select User

A filter on object types can be set to reduce the listing of all user names. The location states the machine name where the user account is stored, this can be the local workstation or the central domain controller machine. The edit box below the names can be typed in and verified afterwards by pressing the Check Names button.

All users known by the machine selected in Location can be displayed by pressing the Advanced... button.

The list of all known users will be displayed after clicking the Find Now button.


Select Domain User

A filter on object types can be set to reduce the listing of all user names. The location states the machine name where the user account is stored, this can be the local workstation or the central domain controller machine. The edit box below the names can be typed in and verified afterwards by pressing the Check Names button.

All users known by the machine selected in Location can be displayed by pressing the Advanced... button.

The list of all known users will be displayed after clicking the Find Now button.


About DCOM Help

Basic information about the DCOM Help

The DCOM Help provides information about the nessecary settings of DCOM security.

About this Help File:
Version: 2.0 Build 14
Released: 01 June 2006

(c) Copyright ascolab GmbH 2006. All Rights Reserved.

Important: using this Help File indicates your acceptance of the following AGREEMENT AND DISCLAIMER


About ascolab GmbH

The ascolab GmbH supplies software services in the field of industrial communication. The corporation consists of three main business divisions “Software Architecture & Development”, IT Consulting & Service” and OPC Consulting & Certification”. With their services the ascolab GmbH contributes the worlds leading manufacturers of distributed automation products to software interoperability and continuous information flow up to the enterprise domain.

Postal Address: | Contact:
ascolab GmbH Am Weichselgarten 7 91058 Erlangen GERMANY | Tel. +49 9131 69 1120 Fax. +49 9131 69 1128 info@ascolab.com www.ascolab.com

Important: using this Help File indicates your acceptance of the following AGREEMENT AND DISCLAIMER


DCOM Help

Disclaimer of Warranty and Liability

YOU SHOULD CAREFULLY READ THE FOLLOWING USER AGREEMENT AND DISCLAIMER OF WARRANTIES AND LIABILITIES ("AGREEMENT AND DISCLAIMER") BEFORE DOWNLOADING OR USING ANY FREE SOFTWARE AVAILABLE FROM ASCOLAB GMBH ("ASCOLAB"). THIS AGREEMENT AND DISCLAIMER APPLIES TO ANY AND ALL FREE SOFTWARE PRODUCED BY ASCOLAB. DOWNLOADING OR USING THIS SOFTWARE INDICATES YOUR ACCEPTANCE OF THIS AGREEMENT AND DISCLAIMER. IF YOU DO NOT AGREE WITH THIS AGREEMENT AND DISCLAIMER, YOU MAY NOT DOWNLOAD THIS SOFTWARE, AND YOU MUST IMMEDIATELY DELETE ALL COPIES OF THE SOFTWARE IN YOUR POSSESSION.
  • ASCOLAB does not warrant that this software will download correctly or that it will install correctly on your machine. ASCOLAB and its affiliates do not warrant that the functions contained in the software will meet your requirements or that the operation of the software will be uninterrupted or error-free or that any software defects will be corrected. If this product is a beta release, ascolab does not warrant that the commercial release of this product will be backward-compatible. This product is provided solely on an "AS-IS" basis, and neither ASCOLAB nor is affiliates make any claim as to fitness for a particular purpose whatsoever. To the maximum extent permitted by law, ASCOLAB and its affiliates disclaim all warranties, expressed or implied, including but not limited to, implied warranties of merchantability or fitness for a particular purpose.
  • ASCOLAB and all its affiliates have no liabilities for consequential damages. In no event shall ASCOLAB or any of its affiliates be liable for any damages whatsoever (including, but not limited to, damages for loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising out of the use of, or out of the inability to use, this product, even if ASCOLAB and/or its affiliates have been advised of the possibility of such damages. ASCOLAB reserves the right to modify or update any part of this Agreement and Disclaimer without prior notification.
  • If sections or individual terms of this statement are not legal or correct, the content or validity of the other parts remain uninfluenced by this fact.