Navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
Set UseWUServer = 0x00000000 (0)
Josh also suggested a server restart, which I did not do, and the change in the setting was apparently sufficient as the server would now accept the command and not spit it back at me.
As a final check, before continuing with configuration of the OpenSSH server, I ran this PowerShell command to check if it was installed as expected:
PS C:\windows\system32> Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Name : OpenSSH.Client~~~~0.0.1.0
State : Installed
Name : OpenSSH.Server~~~~0.0.1.0
State : Installed
So that now looks better than the red error lines. Now to get on with configuring.
Final thoughts: Why would WSUS be configured for a stand-alone server? and if it is then surely it is just a proxy for getting updates in any case, and should be used auto-magically. Apparently what is happening here is that in the Microsoft ‘user-friendly pretty picture interface’ WSUS works quietly in the background doing the updates, but if we step into the dark-side of command lines, the ‘GetWindowsCapability’ command is not intelligent enough to know that it might want to check-in with WSUS first before doing a dummy-spit.
My C: drive (SSD) was short on space and one of the culprits is iTunes Backups. So this article is how to change iTunes backup location on Windows 10.
Obviously using an SSD for performance on a desktop is great, but not so great when you find that it is almost full.
Using WinDirStat, a long time favourite utility, I confirmed that aside from the ever disk hungry Windows 10 install, the next highest consumer of my precious SSD disk space was iTunes Backups directory.
So I could rid myself of some of the older iPhone and iPad backups on my drive, but I thought I would simply relocate it to my slower, but much larger D: drive where the capacity is not an issue.
This article from CopyTrans was relating to Windows 7 and selling their products, but it gave me the pointers on what to do.
The key points are:
create a new location on the alternative drive, D: in my case
copy your existing backups to the new location
rename the old backup directory
create a symbolic link to the new location from the old
remove the old backup directory after testing
The main pain points were mklink not being recognised as a command and the need to use case sensitive path names.
Covering the process in detail:
Create a new location on D:
I was already using a path copy from c: for my music copy and I just needed to create the
Copy existing backup files to the new directory – straight forward
Rename the old backups directory as backup-old just in case of accidents
Create a symbolic link
This is where it went pear-shaped as the mklink command in powershell gave me an error
mklink : The term ‘mklink’ is not recognized as the name of a cmdlet, function, script file, or operable program.
This is easily fixed by prefixing the mklink command with cmd /c
so the command syntax is:
cmd /c mklink /J <linked path> <target path>
Which gave me a new symbolic link but an error when I tried to use it:
“Location is not available”
Which I confirmed was an issue with the command because I used all lower case characters and not the case-sensitive version.
Making those two changes the corrected syntax for Windows 10 powershell is:
cmd /c mklink /J “%APPDATA%\Apple Computer\MobileSync\Backup2” “D:\Users\thowden\AppData\Roaming\Apple Computer\MobileSync\Backup”
(Swap the target path for whatever you want to use)
Next I tested by running a backup from iTunes and checking that it was stored in the D: drive.
Finally I deleted the old backups directory from the C: drive.
Side note: The symbolic link directory is created in the standard path and redirects to the alternative path. The directory (or folder) is created with a Windows shortcut symbol. If you get it wrong, just delete the shortcut, it will not delete the target folder.
So my how to change iTunes backup location on Windows 10 was successful.
“At least one other site is using the same HTTPS binding …..” is a prompt that every Windows Server IIS administrator has come across at some point. It arises when trying to change or update an SSL certificate on Windows server IIS platform where there are multiple websites and potentially multiple certificates.
Multiple Sites Using Same IP and SSL
Multiple sites sharing an IP address use a process of host-header recognition in order to accept the in-bound connection. Where this is on port 80 (http) there is no issue.
However, with port 443, the IP address and port number are also bound to a certificate and changing one site certificate will impact all the other sites on the same IP address and port combination. Hence the following Alert (error) message is displayed.
IIS SSL Multiple Sites Alert
Accepting or rejecting really depends on your server and what sites and certificates are actually in use. However, this may impact on the other sites and my past experience has been that other sites can be left in an unstable state either without a binding, a certificate, or a mix-up on which certificate.
Change SSL Certificate for Multiple Sites
Use the following steps to prepare manual change at the command line in order to avoid the above error message and address all sites using the same IP address : port and certificate at the same time.
All the detailed information has been sanitised to use dummy data, you will need to substitute the relevant information for your certificates and server.
First examine the certificates in use opening a command prompt – this is all read activity so Run as Administrator is not required, yet.
certutil -store My
This will display lists of certificates and applications like the following. I selected the 2 that I was looking for as follows:
the old certificate – based on NotBeforeDate – you need the highlighted hash from each certificate
================ Certificate 7 ================
Serial Number: 1234567890abcdef1234567890abcdef1234
Issuer: CN=AlphaSSL CA – G2, O=AlphaSSL
NotBefore: 01/01/2014 11:27 AM
NotAfter: 31/12/2016 11:27 AM
Subject: CN=*.yourdomain.tld, OU=Domain Control Validated
Non-root Certificate
Template:
Cert Hash(sha1): 12 34 56 78 90 ab cd ef 12 34 56 78 90 ab cd ef 12 34 56 78
Key Container = 12345a8277cd156abcd09d20dcba5c31_g3239vv5-8181-1234-b6ba-bbbb
78ccd34
Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test FAILED
CertUtil: -store command completed successfully.
and the new certificate – based on NotBeforeDate
================ Certificate 4 ================
Serial Number: 67890abcdef12341234567890abcdef12345
Issuer: CN=AlphaSSL CA – SHA256 – G2, O=GlobalSign nv-sa, C=BE
NotBefore: 01/01/2015 9:02 AM
NotAfter: 31/12/2016 11:27 AM
Subject: CN=*.yourdomain.tld, OU=Domain Control Validated
Non-root Certificate
Template:
Cert Hash(sha1): 78 90 ab cd ef 12 34 56 78 90 ab cd ef 12 34 56 78 12 34 56
Key Container = 1234abcd54d7161def4863d4d6b96633_f3239aa5-8080-1234-b6ba-abcd
78ccd34
Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test FAILED
Next, identify the ip address that is in use and, assuming that standard https is being used, port 443. This could be done by checking within IIS first to check which common IP address is being used.
netsh http show sslcert
Which will show all the ssl certificate bindings, or if you know which ipaddress, then be selective
netsh http show sslcert ipport=223.27.11.71:443
Will show the results like:
SSL Certificate bindings:
————————-IP:port : 223.27.11.71:443
Certificate Hash : 1234567890abcdef1234567890abcdef12345678
Application ID : {34567812-3456-7890-abcd-ef123456789d}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
The application ID is what is needed from the above but check that the correct certificate hash (the old one) is associated with this binding.
Now select all the relevant information from the results as shown
Old certificate hash (with spaces removed)
1234567890abcdef1234567890abcdef12345678
New certificate hash (with spaces removed)
7890abcdef1234567890abcdef12345678123456
and the AppID
{34567812-3456-7890-abcd-ef123456789d}
The following two steps will need a new elevated command window selected with ‘Run as Administrator’
When installing Windows RDS stand-alone server per user should not be used on a workgroup based server, i.e. there is no domain to authenticate the “per User” users.
There is a warning about it when adding licenses but it does not prevent you from adding them in per User mode.
While it seems odd that this is an issue when there is still Local User authentication available, it is apparently the case and the RDS server will not provide access, or at least will not assign licences. That said, I have not tried it in that mode.
The good thing is that you can change from per User to per Device at any time with the RD Licensing Manager using the Convert Licences option.
Converting licences can be done in either direction at any time so swapping is permitted.
