Remote Desktop: printer names not matching / event ID 1111

Sometimes, printer drivers names can differ between different Windows versions. This is problematic when connecting to a remote desktop server, as the printer’s name is used to look up the correct driver to use. When the printer driver names do not match, event ID 1111 will occur in the Windows Event Log, for example:

Driver RICOH Aficio 2018 PCL 6 required for printer RICOH Aficio 2018 PCL 6 is unknown. Contact the administrator to install the driver before you log in again.

When you look at the installed driver list on the remote desktop server, we see:

Ricoh Aficio 2018 PCL6

Note the lowercase manufacturer and the removed space between “PCL” and “6”. The solution is to create a mapping file that matches up the printer’s names, again allowing successful waste of paper.

Modify the registry

First we must tell Remote Desktop Services where to find our mapping file. To do that, open the registry and navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd

Add two new string values

  • Value Name: PrinterMappingINFName
  • Value Data: C:\printmap.inf
  • Value Name: PrinterMappingINFSection
  • Value Data: Printers


Create the mapping file

Next, create a plain text file, C:\printmap.inf, with the following content:

“RICOH Aficio 2018 PCL 6” = “Ricoh Aficio 2018 PCL6”
“Brother DCP-560CN Printer” = “Brother DCP-560CN”

printermap2The format of the “Printers” section is as follows:
Left-hand side: name as presented by the client (what the client reports and what you see in the event log)
Right-hand side: correct printer name as listed on the server (the driver’s name listed in print management)

You can add multiple printers.

Logoff and logon

The user should log off and log back on again. The printer should now be installed and the event ID 1111 shouldn’t occur anymore.

Exchange 2013: E-mail stuck in Outbox

When testing Exchange 2013, with almost everything untouched, I was unable to send e-mail. The e-mails were stuck in Outbox with no error messages reported to the client.

When going through the Application Windows event log, the following warning is logged. My Exchange server’s name is EXHANGE1:

Source: MSExchangeFrontEndTransport
Event ID: 1035
Task Category: SmtpReceive

Inbound authentication failed with error LogonDenied for Receive connector Client Frontend EXCHANGE1. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [::1].

It appears by default, the “Client Frontend” receive connector won’t allow connections from its own server.

To fix it, open the ECP and navigate to “mail flow” -> “receive connectors”. Double click “Client Frontend “. Go to the “security” tab and under permission groups, tick “Exchange servers”. Click “save”.

exch-outbox-1 exch-outbox-2

I had to delete the e-mail that was stuck in Outbox, but after restarting Outlook, new e-mails were being sent to internal recipients like they were supposed to.