Tag: Windows Administration

PowerShell – Convert DER Encoded Certificate file into a Base64 .cer

C:Amie/ / Microsoft, Programming, Windows Server

System Requirements:

  • Windows PowerShell

The Problem:

If you have a binary encoded .cer (certificate) file that you need to get into a Base64 format, you can either follow the advice and use OpenSSL to convert it or you can import it into the Windows Certificate Store and re-export it.

If you want to do it automatically, without having to download and install anything else, neither option is particularly appealing.

The Fix

You can use the following function to convert the binary encoded file into a Base64 ASCII encoded file

function Convert-CertificateBinaryToBase64 {
param( [string]$SourceFile, [string]$DestinationFile )
$cert = get-content "$SourceFile" -Encoding Byte
$content = @(
'-----BEGIN CERTIFICATE-----'
[System.Convert]::ToBase64String($cert, 'InsertLineBreaks')
'-----END CERTIFICATE-----'
)$content | Out-File -FilePath "$DestinationFile" -Encoding ASCII
}

Example usage

Convert the file, retaining the source file

Convert-CertificateBinaryToBase64 -Sourcefile 'C:\myBinary.cer' -DestinationFile 'C:\myBase64.cer'

Convert the binary file, overwriting it with the Base64 file

Convert-CertificateBinaryToBase64 -Sourcefile 'C:\myCertificate.cer' -DestinationFile 'C:\myCertificate.cer'

Automatically Scripting Windows Startup Scripts and Shutdown Scripts using the Command Line

C:Amie/ / Microsoft, Programming, Software

System Requirements:

  • Windows 2000, XP Professional, Vista Business, 7 Professional, 7 Enterprise, 8 Professional, 8 Enterprise, 8.1 Professional, 8.1 Enterprise, 10 Professional, 10 Enterprise
  • Windows Server 2000, 2003, 2008, 2008 R2, 2012, 2012 R2, 2016
  • Windows Scripting Host 5.8 or higher

The Problem:

It’s been a problem since 1999. You want to install a Startup or Shutdown Script on a local Windows machine without having to go through GPEdit.msc to manually populate the user interface necessary to install the script processing hook.

Well, now you can do it automatically!

More Info

So here is a VBScript api file which does the work for you to install either a Startup or Shutdown script from the command line. This installs the script as part of the Local Windows Group Policy processor, which on Domain Joined systems will be executed before Domain Logon Scripts.

  • No warranty is offered or implied. Use this script at your own risk
  • Please do not redistribute this script, please link to this page [Perma-link: http://www.c-amie.co.uk/qlink/?id=142]
  • You may not sell or profit from the use of this script
  • You may not bundle this script as part of an application deliverable or payload
If you found this useful, please consider making a donation or using the Amazon Affiliates Link to help support this site!

Download: AddLocalGpStartupScript.zip [4KB]

Usage

You can call the script from the Command Line or a bat (batch) file using the following syntax

cscript.exe AddLocalGpStartupScript.vbs <startup|shutdown> <path> <arguments>

You can view the help screen and examples at any time by calling

cscript.exe AddLocalGpStartupScript.vbs /?

Examples

Writes http://www.c-amie.co.uk/ to the file C:\LogFile.log during startup

cscript.exe AddLocalGpStartupScript.vbs startup "cmd.exe" "/c echo http://www.c-amie.co.uk>>C:\LogFile.log"

Opens C:\LogFile.log in Notepad during shutdown

cscript.exe AddLocalGpStartupScript.vbs shutdown "notepad.exe" "C:\LogFile.log"

Calls D:\Scripts\MyScript.cmd with no arguments during shutdown

cscript.exe AddLocalGpStartupScript.vbs shutdown "D:\Scripts\MyScript.cmd"

Executes the PowerShell Script C:\MyPsScript.ps1, ignoring the System Execution Policy during startup

cscript.exe AddLocalGpStartupScript.vbs startup "powershell.exe" "-ExecutionPolicy bypass -windowstyle hidden -file C:\MyPsScript.ps1"

Performing a Test

If you want a simple test to find out if it works, try the following which writes a log trace to two text files on the root of C Drive:

cscript.exe //NoLogo AddLocalGpStartupScript.vbs startup cmd.exe "/c echo %date% %time% startup>> c:\startup.log"

cscript.exe //NoLogo AddLocalGpStartupScript.vbs shutdown cmd.exe "/c echo %date% %time% shutdown>> c:\shutdown.log"

Why isn’t there a Logon and Logoff Script Version?

There is actually one and it doesn’t work. The process of installing the Logon Script isn’t quite a simple as the process for a Startup Script because it has to be written into the registry on each user account. Consequently, until such a time that I have the will to automate this part, while it performs the installation legally, it doesn’t execute unless you go in and press the apply button on the Logon Script UI.

Preventing a driver from automatically installing from Windows Update on Windows 10 (when it keeps reinstalling before you can run the driver blocking tool)

C:Amie/ / Microsoft

System Requirements:

  • Windows 10

The Problem:

Microsoft’s descent into Apple design and general irrelevancy continues unabated with design time decisions for Windows 10. Obviously when drivers get released onto Windows Update, they’re going to work for everyone. Obviously.

In my experience the main issue is with integrated chips from the large PC OEM’s (Dell, HP etc). The subtle modifications that they make in their own proprietary releases of their “2010” driver when do not necessarily directly map onto the generalised driver with the same PnP ID’s being detected from Windows Update.

In the last week I’ve had to deal with this no less than 8 time on 6 separate occasions. I, like most people in IT, have encountered this many times before however it has usually been with fairly large driver updates that require a reboot – prolific Windows 10 dual screen problems with Windows Update Intel HD Graphics drivers anyone?

So unlike previous Windows versions, there is no longer a way to stop Windows Update automatically installing updates immediately using the UI, you have to resort to group policy to have any chance of delaying it. In Windows 10 there is also no way to block certain updates if you do not want them / they don’t work.

Of course Microsoft’s business decision behind this end user horror is quite simple: Too many people blocked or are blocking KB3035583 (the Windows 10 installer update for Windows 7 and 8.x) preventing them from force feeding you Windows 10. They also want to de-fragment their ecosystem (I can empathise with this) and consequently they want to ensure that people are being spoon fed the latest feature updates as soon as possible under the new Windows feature release cycle.

Of course, if you get a bad update or a bad driver, now that there is no way to block it, you will uninstall it and it will simply come back.

The problem is exacerbated with small driver downloads (in the kilobytes range) that do not require reboots. In my most recent cases a 2009 HP Laptop Webcam. a 2010 HP Laptop Fingerprint reader and a 2008 Toshiba laptop touch screen driver. By the time that you have uninstalled the bad driver, rolled back to ‘no driver’/a working driver, run Windows Update to make Windows aware that there is a bad one available and then in turn run the Window Update Show/Hide Tool. Windows has already reinstalled the bad driver and as a consequence the WU Show/Hide tool is unable to give you the option to block the driver.

Bravo Microsoft. Bravo!

More Info

As eluded to above, the issue is one of timing. Windows 10’s brutal and where possible immediate desire to install anything that comes down the update channel is breaking the sequence necessary to correctly use the WU Show/Hide tool.

The required sequence is:

  1. Uninstall defective device, deleting the old driver
  2. Run Windows Update so that the local Windows Update Available Updates Catalogue shows an available driver update for that device
  3. <Windows Update should NOT do anything at this point>
  4. Run the Windows Update Show/Hide Tool
  5. Block the bad driver update
  6. Re-scan Windows Update to clear the update from the Available Updates Catalogue
  7. Install updates manually / after a sensible delay

In practice, at step 3 Windows Update – now aware that there is a driver waiting – is simply installing the bad driver again. This prevents you from running the WU Blocker tool. The problem is exacerbated by small updates (or fast Internet connections) because there isn’t a delay between Windows realising that there is an update and taking the time to download it before executing the Install.

This delay is useful for things like the Intel HD Graphics problem because the driver files is over 120MB and in many cases this gives you enough time to run the WU Blocker tool successfully.

The Fix

Yes, you can mess around with Group Policy to fix this – unless of course you are on a home edition. Yes, you can also modify the driver installation policy, however again this isn’t always desirable. So I present a simple way to solve this.

  1. Download the Windows Update Show/Hide (blocker) tool from KB3073930
  2. Open Windows Explorer at C:\Windows\SoftwareDistribution\Download
  3. Open en elevated command prompt and type:
net stop wuauserv
  1. Return to C:\Windows\SoftwareDistribution\Download and delete everything in the folder (but not the folder itself) – this deletes the installer cache for the driver
  2. Right click on the C:\Windows\SoftwareDistribution\Download folder itself, choose properties
  3. Open the security tab
  4. Click Edit to change permissions
  5. Select the SYSTEM account from the accounts list
  6. In the Deny column next to the permission for “Write” place a tick – JUST place a tick next to Write, that is all that is needed!
  7. Click OK twice to return to Windows Explorer – accepting any messages and warnings about Deny actions and system folders
  8. Go to device manager, uninstall the defective device – ensuring that you select the option to delete the driver along with it
  9. Run Windows Update
  10. Windows Update will now attempt to install the device, however it will fail with error code 0x80246007
  11. Now run the Windows Update Show/Hide Tool, block the update
  12. Return to Windows Update and re-scan for the update to flush it out of the available update list
  13. Go back to setup 5 and REMOVE the Deny Write permission tick to undo your changes
  14. Return to Windows Update and re-scan for updates. Windows Update should inform you that your device is up to date and will not attempt to install the driver

View: Windows Update Show/Hide Tool

Error 1635 from Microsoft Office Installer when installing from a SMB File Source

C:Amie/ / Microsoft, Software

System Requirements:

  • Office 2007
  • Office 2010
  • Office 2013 (Enterprise)
  • Office 2016 (Enterprise)

The Problem:

You’re one of the lucky people who has access to a version of Office that doesn’t need to use the awful “Click to Run” to perform the install. You are trying to use SCCM, Group Policy, a BAT file or some other remote invocation method to deploy Office from a source repository on a SMB file share.

Office starts to install, the installation looks like it is working and even one or two app’s appear on the start menu… before it unexplainably performs a roll back and uninstalls itself leaving your machine with no Office installation.

If you check the log files (in %temp% or c:\users\<user>\AppData\Local\Temp by default) you will find a Windows Installer Error 1635 entry listed before it commenced the rollback.

More Info

Windows Installer Error 1635 is “This patch package could not be opened. Verify that the patch package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer patch package”.

If you are using SCCM, then you are probably attempting to execute this through the NT System account or via local admin.

Obviously you’ve checked the share permissions, perhaps even enabled a Null Session Share to allow anonymous access to the share… and it still doesn’t work. The client script is obviously executing successfully because the setup programme loads and runs for 10 minutes or more quite happily before erroring out.

The Fix

Quite simply, save yourself a headache and script the process to call the Office setup.exe from the local machine rather than directly against the SMB Share. This will solve the problem. Something in line with the following will download the installer and files from the repository to the OS Temp directory, execute the installer process and then clean-up

mkdir C:\Windows\Temp\OfficeSetup

xcopy "\\server\share" "C:\Windows\Temp\OfficeSetup" /Y /E /V /C /Q /H /R

:: Pre-Install actions here

call "C:\Windows\Temp\OfficeSetup\setup.exe" <switches go here>

:: Post-Install actions here

rmdir "C:\Windows\Temp\OfficeSetup" /S /Q