Printing directly from IRIS/Caché on Windows Server to a local shared printer (or creating a remote file) on a Windows client pc

When you install an IRIS or Caché instance on Windows Server, you'll usually need to install it under a specific user account that has network access permissions. This is very handy when you needs to access network resources for creating files or directly accessing printers.

TL;DR: see key takeaways at the bottom!

When you need to change the Windows user account the IRIS/Caché service is running as, you can configure (after installation):

• for IRIS (also see the docs): 

  <install-dir>\bin\IRISinstall.exe setserviceusername <instance-name> <username> <password>

• for Caché (also see the docs and a post from @John Murray): 

  <install-dir>\bin\cinstall.exe setserviceusername <instance-name> <username> <password>

   

When you have the following situation:

• IRIS/Caché running on Windows Server
• a Windows client pc with a local printer connected (or you need to read from/write to a file on this pc)
• IRIS/Caché running on the server as ISCService user (make sure this user has service logon permission)
• on the Windows client pc, the ISCService user is created with the same credentials as on the server
• the Windows client pc needs to enable File and printer sharing over the LAN network(s)
• if you need to cross LAN boundaries, add the other LAN's to all (Private Profile) File and Printer Sharing rules under scope (Remote ip address) in Windows Firewall - Advanced settings - Inbound rules

Example: you have a client pc WAREHOUSE1 (with ip address 192.168.1.20) with a local printer connected at a usb port (or another local port) and the printer is shared with share name LABELPR.

In your ObjectScript code, you can access this printer directly from your server using (as documented here, this also works over local network boundaries, e.g. in a vpn situation connecting different LAN's with their own local IRIS/Caché servers):

SET DEV="|PRN|\\192.168.1.20\LABELPR" # use client pc ip address to cross LAN boundaries
OPEN DEV::2 IF '$TEST WRITE "Printer not accessible" QUIT
USE DEV WRITE "..." # write commands to printer to print e.g. a label or ticket
CLOSE DEV

Typically, printers for labels or tickets are using "text command" drivers you can directly write to using text strings containing escape codes, depending on the make of the printer, like e.g. Epson ticket printers, Zebra label printers or Brother QL label printers.

Btw, the printer can also be accessed only from within the local network using it's UNC path:

SET DEV="|PRN|\\WAREHOUSE1\LABELPR"
...

Recently, you'll encounter issues trying to print directly to a printer (or creating a remote file) from IRIS/Caché: you can't access a shared printer (or a file share) anymore from your ObjectScript code. Microsoft strenghtened security in their SMB protocols and their RPC printing protocols.

This article provides some pointers you can try out to solve these issues. On the internet, you'll find a load of suggestions, but unfortunately, most of them don't work. There are different steps you'll need to take depending on the Windows Server version and the Windows version on the client. From my experience on Windows Server versions 2012R2, 2016, 2019 and 2022 and client pc Windows versions 10 and 11 22H2, these are the steps to make printing work:

• IRIS/Caché on Windows Server 2012R2 or 2016: in this case the RPC printing protocol setting is the culprit:
  • using a printer connected to a Windows 11 Pro 22H2 client: you need to enable the 'RPC over named pipes' printing protocol again (disabled by default in version 22H2). Open Group Policy Editor and go to 'Computer Configuration - Administrative Templates - Printers' and configure setting 'Configure RPC listener settings' to 'Enabled', 'RPC over named pipes and TCP', 'Authentication protocol': 'Negotiate' (from my tests on Windows Server 2016, changing this RPC setting was not needed in my tests)
  • on Windows 11 Home 22H2 client pc's, Group Policy Editor is not available, you'll need to configure it using Registry Editor. add the setting using:

    reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\RPC" /v RpcProtocols /t REG_DWORD /d 0x7 /f

     
  • using a printer connected to a Windows 10 client: no settings needed there, it should just work
  • for the creation of remote files by the IRIS/Caché server on a client pc in the LAN network (both for Windows 10 and 11), no additional settings are needed, it just works (provided the Caché service user had the same credentials as the same user on the client pc)!

• IRIS/Caché on Windows Server 2019 or 2022: from my field tests, it seems the IRIS/Caché process running under the ISCService user is using the logged on as user account on the server when connecting to the client pc. If you're logged on e.g. as Administrator, the irisdb.exe or cache.exe process will try to connect to the client pc using the Administrator user instead of the ISCService user. As a consequence, the client pc refuses the connection ... To solve this connection problem:
  • on the Windows Server (!), open Control Panel - User Accounts - Manage your credentials - Windows Credentials: Add a Windows credential: add the name or ip address of the client pc (WAREHOUSE1 or 192.168.1.20) with the ISCService user name & password. As soon as you do this, you can connect again to the client pc from your ObjectScript code.
  • This worked both with Windows 10 and Windows 11 clients.
  • The RPC setting is not needed in this case, but you can configure it to 'RPC over named pipes and TCP', it won't harm (only available on Windows 11 22H2 clients)
  • adding Windows credentials on the server is also needed for the creation of remote files by the IRIS/Caché server on a client pc in the LAN network (both for Windows 10 and 11)!

FYI, some pointers to the relevant Microsoft articles on these issues: changes in Windows 11 22H2 and the add Windows Credentials suggestion from Don Baker.

For older Windows servers and clients, you may need to enable SMBv1 too (this is strongly discouraged due to security flaws, only use this when really needed, I couldn't test this combination).

Key takeways from these tests with different Windows versions:

• make sure the IRIS/Caché service on Windows Server is running under it's own user account with network access
• on remote (client) pc's you need access to (for printing or file access), make sure the same user account is created (+ same password)
• on your Windows Server, add Windows credentials for each client pc you need to access
• on Windows 11 22H2 client pc's, make sure RPC listener settings are set to RPC over named pipes and TCP