Restrictions for Connect:Direct for Microsoft Windows
Connect:Direct® for Microsoft Windows version 6.2 has the following restrictions:
- When performing a new or upgrade installation of Connect:Direct with Control Center Director, Integrated File Agent cannot be selected as an option.
- When Integrated File Agent is selected as an installation option, the Connect:Direct Windows installation briefly displays a Command Prompt. Then, the installation completes successfully.
- When the Connect:Direct for Microsoft Windows installer is run with only the Requester selected, a dialog box reporting a spurious error message is displayed. Clicking OK causes the installation to complete successfully.
- When an upgrade to Connect:Direct Windows 6.2 is performed with the option to uninstall the previous version selected, the previous version's Service entry is not removed.
- Connect:Direct for Microsoft Windows version 6.2 has not been tested or certified for use in a Load Balanced environment and is not supported.
- Process Directory in initparms can only be configured by the Windows Administrators or members of the local Administrators group.
- Connect:Direct for Microsoft Windows does not support upgrading from Connect:Direct Windows 4.5xx or earlier.
- A password-less proxy can only be added or configured by the Windows Administrator or members of the local Administrators group.
- While importing
Initparm.cfg, validation of Password Exit DLL file and Password Exit Hash is restricted to length check.
- In silent installation , validation of Password Exit Hash is limited to length check .
- There is no GUI support for creating ECDSA signed certificates.
- You can keep an earlier version of Connect:Direct for Microsoft Windows on the computer on which you are installing Connect:Direct for Microsoft Windows version 6.2.
- Connect:Direct for Microsoft Windows version 6.2 NT Broadcast do not send messages on 64-bit operating systems.
- Built-in variables should only be specified in a SUBMIT statement within a Process if the statement will be executed on a Connect:Direct for Microsoft Windows version 4.6 (or later) node or another IBM® Connect:Direct version that supports built-in variables.
- Temporary addresses, which are a security feature of the IPv6 protocol, are generated
automatically by the operating system and are used only for outbound connections. These addresses
have a short life span and are replaced by other temporary outbound addresses. This feature of the
IPv6 protocol causes problems with Netmap Checking. If the outgoing address of the PNODE randomly
changes and netmap checking is enabled by the SNODE, the SNODE always refuses the connection because
the IP address of the PNODE never matches the IP address configured for it.
You can work around the problem created by temporary addresses in two ways:
- On the PNODE, configure outgoing.address in the initialization parameters
file using the IPv6 address for the PNODE server. This ensures that the IP address that the PNODE
uses to create a connection to a remote node is always constant. Consider the following:
- If a PNODE has several IP addresses configured, for example, two IPv6 addresses and two IPv4 addresses, configure the outgoing.address initialization parameter with one IPv6 address. This address can then be used to connect to an SNODE configured with either IPv6 or IPv4 addresses.
- If a PNODE wants to use an IPv4 address to connect to an SNODE that has both IPv6 and IPv4 IP addresses, ensure that the tcp.api.port and tcp.host.port initialization parameters of the SNODE are configured with an IPv4 address and port.
- Disable temporary addresses for the PNODE. This is a configuration option in the Windows
networking component. If the temporary addresses are not generated, connections to a remote that use
the IPv6 protocol use the configured IPv6 address.Note: To disable temporary addresses in Windows operating systems, see the Microsoft Windows documentation.
See RFC 3041 for more information on IPv6 temporary addresses.
- On the PNODE, configure outgoing.address in the initialization parameters file using the IPv6 address for the PNODE server. This ensures that the IP address that the PNODE uses to create a connection to a remote node is always constant. Consider the following:
- If you modify user authorizations from the IBM Connect:Direct server and the IBM Connect:Direct Requester is attached, you must detach and reattach to the IBM Connect:Direct server. When you reattach to the IBM Connect:Direct server, IBM Connect:Direct Requester reads the updated user information.
- Connect:Direct for Microsoft
previously supported the DESKTOP(YES) parameter in the SYSOPTS statement of a IBM Connect:Direct Process. This parameter
enabled user programs launched by the IBM Connect:Direct service to interact with the
Windows desktop. Currently this parameter functions only on versions of Microsoft Windows prior to
Windows Vista and Windows Server 2008. For security reasons, Microsoft has removed support for
Interactive Services from those two operating systems. Microsoft blocks any attempt by a Windows
service to interact with the desktop. IBM Connect:Direct administrators should begin
to remove the DESKTOP(YES) parameter from all Connect:Direct for Microsoft
scripts. Alternatively, you can switch DESKTOP(YES) references to DESKTOP(NO).
To ease the transition of upgrading to Connect:Direct for Microsoft Windows, IBM Connect:Direct detects when a process using DESKTOP(YES) is submitted on a Windows system that does not support Interactive Services. When DESKTOP(YES) is detected, IBM Connect:Direct dynamically switches to DESKTOP(NO) and records the following warning in the statistics:
LPRS020I Invalid DESKTOP value specified. DESKTOP=YES is not supported on this version of Windows. The RUN TASK / JOB will continue with DESKTOP reset to NO.
After this warning is written to IBM Connect:Direct statistics, the Process is allowed to continue as if DESKTOP(NO) had been originally specified.
This transitional feature works only if the RUN TASK or RUN JOB is capable of running without desktop interaction. That is, if manually switching DESKTOP(YES) to DESKTOP(NO) would cause the IBM Connect:Direct Process to fail, then the dynamic switch to DESKTOP(NO) will not be an effective solution. If the program executed by the RUN TASK/JOB is unable to execute without user interaction then that program must be changed so that it no longer needs user interaction.
- Local transfers on the same computer, such as PNODE-SNODE could fail with error
FASP041E: FASPinitialization failed. FASP is not very well suited for this kind of a network connection. Use TCP/IP for local transfers instead.