fatal: Authentication failed git on Windows

If you change your password, or the git repository password is changed you can get the following error. In this situation you cannot make any changes or if it is a private repository even make a clone or pull.

Luckily there is a quick solution:

Navigate to:
Control Panel\All Control Panel Items\Credential Manager

rundll32.exe keymgr.dll,KRShowKeyMgr

Remove the git entry and try again (now you will be asked again for your username and password).

Automatic way of making a lot of folders

There are multiple reasons why you need a lot of pre-created folders. Making the folders by hand would be a very boring time intensive job. So make use of the available script languages in your system. I have written some examples below.

Create multiple folders with PowerShell

Create multiple folders with CMD

Create multiple folders on Unix

New-VM Value cannot be null. Parameter name: source

The following error: “parameter name source cannot be null” is just an exception in the VMWare.VimAutomation.Core module.
With this error its hard to find the actual issue. The version i’ve running:

The actual issue is that there is no  “-NetworkName” or -PortGroup parameter is given. So adding this wil fix the issue.

Just curious so i updated the module to the newest available.
Updated VMware.VimAutomation.Core to version: 11.5
Now the error is more clear.

My test command:

Error: New-VM: PowerCLI could not automatically determine a network to which to attach the VM. Specify a network explicitly using the -NetworkName parameter.

In the newest PowerCli version the error is more clear.
Add a -NetworkName or -PortGroup to fix the error.

Happy Automating 🙂

PowerShell: Execution of scripts is disabled on this system.

This error occur when the default PowerShell execution policy is active on the system, the default policy is restricted on fresh Windows Installations. Windows Execution policy is a security mechanism from Microsoft to protect your system against running unwanted PowerShell scripts on your system. But not handy for system administrators like us. To disable this security and enabling the possibility of running PowerShell scripts you can run a simple PowerShell command.

As described in the Help file of command: Get-ExecutionPolicy

* The execution policy is part of the security strategy of Windows PowerShell. It determines whether you can load configuration files (including your Windows PowerShell profile) and run scripts, and it determines which scripts, if any, must be digitally signed before they will run.

The effective execution policy is determined by the policies that you set by using the Set-ExecutionPolicy cmdlet and the “Turn on Script Execution” group policies for computers and users. The precedence order is ComputerGroup Policy > User Group Policy > Process (session) execution policy > User execution policy > Computer execution policy. For more information about Windows PowerShell execution policy, including definitions of the Windows PowerShellpolicies, see about_Execution_Policies

See about_Execution_Policies (http://go.microsoft.com/fwlink/?LinkID=135170).
Personally I use the following command, because I can read scripts and see if they are OK:

If you want some kind of security and run only scripts from trusted publishers.

Authentication failed because the remote party has closed the transport stream

This error can occurs when your client is setting up a secure transport stream using TLSv1.1 or TLSv1.2 to a webservice/API for example.
In my case it was the PowerCli module installed on Windows Server 2019 setting up a connection to a VCenter server. The communication between this services is determined by the client OS and the installed .NET version.

There are 2 resolutions:
1. (The Hard way:) Call your software supplier and let them update their code.

2. (The easy most preferred way:) For enabling this communication in your .NET Framework configuration you can edit your registery.

Add the following registery key.

For 32-Bit processes:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\[.NET_version]
Add: Type: DWORD Name: SchUseStrongCrypto Value: 1

For 64-bit processes:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\[.NET_version]
Add: Type: DWORD Name: SchUseStrongCrypto Value: 1

I made the change for both architectures.

Minion did not return. [No response]

There are multiple reasons why your minion did not return.
Hereby a couple checks you can do for troubleshooting your Salt – minion configuration.

First, check if your minion is running.

On unix:
systemctl status salt-minion
On Windows:
Check it with services.msc

Second, check if you can resolve the salt master.

If not, add to dns or hostfile

Tirth, check your firewall.

On both master and minion.

Fourth, check if you can ping your minion.

salt VM01 test.ping

If not..
Then mostly increasing the timeout value of salt master fix it
Sudo nano /etc/salt/master
Search for timeout

Increase it to for example 60

Restart your salt-master.
sudo pkill salt-master
sudo salt-master -d

Fifth, reinstall your minion.

If you have other options then this, be free to comment 😊

Create Windows user using SALTstack

The first thing i did using salt stack was creating a local windows user. Creating users on different OS builds are fully supported by using the built-in salt functions.

First create a mapping in your top.sls config which point to your Windows state directory.

Sample config in top.sls Defining 2 hostnames, one with a wildcard for matching a server group.

Content of the win_generic.sls

In this example I use pillar for securing passwords. If you don’t use pillar, just use a plain text password in the password field.
Ill write a blog article how to use Pillar in SALT.

Remove SCOM Management packs with PowerShell

After importing a newer version of SQL Management pack, in our case ( The older SQL Management packs are no longer needed, because the new one is version-agnostic.

As described in the release notes:
This management pack is version-agnostic, which means that you need only it to monitor SQL Server from 2012 to 2017 and higher. The previous management packs for SQL Server 20082012, 2014, and 2016 have reached the end of support. After importing, this management pack behaves differently depending on whether there are already the previous management packs installed or not. If those are not installed, the management pack will discover and monitor SQL Server 2012, 2014, 2016, 2017 and higher right out of the box, as the previous management packs do that. In the case when there is one or several of the previous management pack for SQL Server 2012, 2014, and 2016, the version-agnostic management pack will disable the discovery and monitoring for those versions of SQL Server that are already monitored by the previous management packs. It is to avoid double monitoring.

Now, it’s time to delete all older SQL Management packs.
Open your Operations Manager PowerShell window. If you cannot find the shortcut on your management server, you can also do a “import-module operationsmanager”

The trust relationship between this workstation and the primary domain failed

There are multiple reasons for getting this event. It mostly happen when you restore a domain joined server or workstation.
Event details:

EventID: 5719

This computer was not able to set up a secure session with a domain controller in domain “” due to the following:
There are currently no logon servers available to service the logon request. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

There are multiple ways to fix this.
Just log in with your LOCAL (not domain) credentials.

1.The PowerShell way (yeah):

2. With netdom.exe using your Windows Command Prompt:

3. With the GUI:
Change your domain membership to WORKGROUP, reboot. And join again, reboot.

Kill a stopping service in Windows

Sometimes if you restart or stop a Windows service it wont stop. The Windows Service is stuck in the “stopping” state. If you cannot reboot your server or workstation for whatever reason you can kill the task using taskkill.exe.
First, open CMD (command prompt) as Administrator.
Then query the process ID (pid) using:

Look for the PID.

Or using PowerShell with a force command: