Remote Desktop printer driver name mismatch

Years ago.. about a decade ago, we used to use some kind of .ini or .inf file to tally up mismatched printer driver names between client & server when using Terminal Services printer redirection.
It’s long winded process, and I can’t really find any information on how to do it now. I did eventually find the information about a month ago, but it wasn’t easy to find, and when I looked at it I decided I just wanted to go home.

This problem is beginning to occur more frequently again now between Windows 10 and Windows 7. The situation is a Windows 7 Professional computer in the office, and a Windows 10 computer at home, trying to use Remote Desktop to access the Windows 7 computer.

Both HP and Dell, have different names in their Windows 7 drivers vs. the Windows 10 drivers.

So when faced with the same problem again today, I tried a different fix, and it seemed to work just fine.

I changed the driver name in the registry, restarted the Print Spooler, and the name changed in the drivers list. I disconnected / reconnected to Remote Desktop, and the printer redirection worked as it should.

As you can see in the pictures below, the key itself just needs renaming under HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3 (or whatever for your specific driver).

In the screenshot below, I am adding “GDI” to the end of the “Dell B1165nfw Mono MFP” driver name, so that it matches with the new Windows 10 laptop that the person is connecting from.

Here’s the driver name on the Windows 7 Pro RDP host computer at the company:

Here’s the driver name on the Windows 10 client RDP client:

and here is me altering that name back on the Windows 7 Pro computer. I have added ” GDI” to the end, so that the names match.
The print spooler service needed restarting for the updated name to appear.

Prevent server from rebooting *before* remote logon

You’re at the logon screen. The server says “Automatic restart will occur today”. If you log on, it will either restart now, or when you’re finished, and you’ll get some support calls when it’s down!

From your favourite remote support tool, run the following command *before* logging on:

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU /v NoAutoRebootWithLoggedOnUsers /t REG_DWORD /d 1 /f

If you leave the password prompt (click back to the Ctrl-Alt-Del screen), and then go back to log on, you should see that the “Automatic restart will occur today” part of the warning is gone, and you can safely log on.

nginx error 500 php

in /etc/php-fpm.d/www.conf:

catch_workers_output = yes

and most importantly.. comment out the 5xx html page in nginx.conf, so you can see actual errors. Which in my case turned out to be permissions of /var/lib/php/[session, peclxml, opcache, wsdlcache]. They were still group owned by ‘apache’ instead of nginx

/etc/nginx/nginx.conf:

#display some actual useful errors please....
#        error_page 500 502 503 504 /50x.html;
#            location = /50x.html {
#        }

Centos / Fedora firewalld firewall-cmd

I can never remember this…

firewall-cmd --list-all-zones

Look to see which is ‘active’. Should be FedoraServer on Fedora Server. Then..

firewall-cmd --zone=FedoraServer --add-port=80/tcp --permanent

Annoyingly, the –permanent means ‘just add to the startup configuration, but don’t do anything now’. If you leave off the –permanent, then it takes effect right away but only affects the running configuration and will be lost after a restart.

Either way, you need two commands – either the –permanent command above, followed by

firewall-cmd --reload

or, and this is probably wiser in case you do something wrong and lock yourself out, you should do the command without –permanent, then check that all works (no –reload will be needed), then add it in again with –permanent so that the rule will be present after a future restart.

So, in summary:

firewall-cmd --zone=FedoraServer --add-port=80/tcp

(check that things are as you want them)

firewall-cmd --zone=FedoraServer --add-port=80/tcp --permanent

for localhost only stuff (e.g. powerdns stats on 127.0.0.1:8081)

firewall-cmd --zone=trusted --add-port=8081/tcp
firewall-cmd --zone=trusted --add-port=8081/tcp --permanent

To remove / undo:

firewall-cmd --zone=FedoraServer --remove-port=80/tcp
firewall-cmd --zone=FedoraServer --remove-port=80/tcp --permanent

For some known services (not sure which.. maybe it just uses /etc/services ?) you can give the service name instead of the port/protocol:

--add-service=http

instead of

--add-port=tcp/80

etc.

Petya / NotPetya cyber attack 27th June 2017

Petya (a.k.a NotPetya) is another ransom-ware file-encrypting virus worm. The latest big thing.

Apparently it spreads through the same mechanism as the WannaCry virus (NHS cyber attack May 2017), but there are also reports of it being sent through emails.
That method of spreading from one computer to another was due to a security flaw in Microsoft Windows. The code to exploit this flaw, which the US government found years ago but kept to themselves, had been called EternalBlue. A patch/fix for this was released by Microsoft in March 2017, and also included in subsequent update roll-ups.

During the NHS cyber attack crisis, I took steps to ensure that all client’s computer had this and other important updates installed. For this reason, you are already patched against EternalBlue, however you must still be vigilant with regard to opening email attachments.

As it happens, security researchers have discovered a sort of ‘vaccine’, however it will only work for the current outbreak. If the virus does get to your computer, perhaps through the opening of an email attachment, it first checks whether some other files are present on the computer, and if they are, then the virus shuts itself down and does no harm. So this is sort of like a kill switch.

I have sent a popup message to your computer to let you know that these vaccine files have been put in place on your computer, as well as to explain the patch situation above.

Gemalto smartcard reader not working after Windows 10 creators update.

For some reason the Gemalto / eSigner stuff wasn’t working after the Windows 10 Creators update.
The ‘Certificate Propagation’ service would not start, and this was due to policy settings. Apparently the Gemalto stuff doesn’t require this, and has its own method of importing certificates from smartcards.

Regardless, the systray tool said ‘Unknown card’, and this was fixed when the Certificate Propagation service was re-enabled and started:

Set the following key to 00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CertProp]
“CertPropEnabled”=dword:00000001
And start the service: Certificate Propagation.

samba smb3 multichannel on 802.3ad/lacp bond

Still working on this.
Need to alias the bond “ip link add link bon0 name bond0-alias address 11:22:33:44:55:66 type macvlan” doesn’t quite work because the bonding driver just flips through the same slave interfaces regardless of whether alias or original bond0 device is being used.

Next thing to try: alias the slaves and create a separate bond from them. This is on the NAS box (CentOS 7) running NFS and Samba.

On the Windows side, Server 2016 is running on Proxmox which is using a similar quad-NIC LACP bond. A duplicate virtIO interface was added to the Windows guest in Proxmox. Windows guest seems to be sending and receiving over both interfaces quite happily (but only at half rate), not sure what Proxmox/Linux is doing on the host side yet.

Compiling gr-fosphor on Fedora 25 / CentOS 7 with intel opencl

Download the Intel OpenCL runtime & libraries (you don’t need the sdk).
install those RPMs. They will install to /opt/intel/opencl

cd gr-fosphor/build

here is the key step:

cmake -DOpenCL_LIBRARY=/opt/intel/opencl/libOpenCL.so -DOpenCL_INCLUDE_DIR=/opt/intel/opencl/include ..

then just carry on with the normal instructions:

make
sudo make install
sudo ldconfig

Cisco SPA phones not getting IP via DHCP

This is a pain, and I keep forgetting the cause. So to save myself the trouble in future, here it is..

It’s simple – another device has the IP address that your DHCP server is handing out to the SPA504g/spa508g phones, and so the phones are refusing to accept this IP address.

The Cisco SPA phone is being handed e.g. 192.168.1.56 by your DHCP server, but another device is using this IP address already. It may be the DHCP server that is at fault. In my case, Windows 2008 DHCP server does not have a record of some of the existing IPs in use / previously leased. Perhaps the SPA phones are not honoring the lease expiration time and failing to renew, just continuing to use an IP address, and then DHCP server thinks the IP is free to hand out to another phone when it restarts or is unplugged and plugged back in. There’s a DHCP server configuration option to do an ARP check or something before handing out a lease.. might be worth looking into that.

Look in your DHCP lease table, find the MAC of the offending phone, have a look what IP the DHCP server thinks is has leased to the phone. With the phone powered off, check if you can ping that IP. If you can ping that IP, then you know that the DHCP server is OFFERing out an IP address that is already in use.

If the DHCP server is Windows, and the scope is e.g. 192.168.1.11 Р192.168.1.100, then a quick fix is to temporarily change the scope range to something like 192.168.1.60  Р192.168.1.80, thus forcing the DHCP server to hand out a different IP address than the original 192.168.1.56 that it was handing out. The phones will then work, and then you can set the scope back to the original range. The DHCP server will record the lease and hand out that new IP address in future.