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
Or:
rundll32.exe keymgr.dll,KRShowKeyMgr
Remove the git entry and try again (now you will be asked again for your username and password).
Voila!
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.
|
1 2 3 4 5 6 |
$prefix = "TST" $basepath = "c:\Temp" 1..100 | % {new-item -Type Directory -name $($Prefix.$_) -path $basepath } #Or with formatting the numbers to 3 decimals. 1..100 | % {new-item -Type Directory -name $([string]::Format("$Prefix.{0}", $_.ToString("000"))) -path $basepath } |
|
1 |
for /l %i in (0,1,999) do md %i |
|
1 |
mkdir TST.{000..099} |
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:
|
1 2 3 4 5 |
PS > get-command new-vm CommandType Name Version Source ----------- ---- ------- ------ Cmdlet New-VM 11.3.0.... VMware.VimAutomation.Core |
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.
|
1 2 3 4 5 |
PS > get-command new-vm CommandType Name Version Source ----------- ---- ------- ------ Cmdlet New-VM 11.5.0.... VMware.VimAutomation.Core |
My test command:
|
1 2 3 |
$VMhost = get-vmhost -name "TST01" $DS = Get-datastore -name "DS1" New-VM -VMHost $vmhost -name "TST01" -Datastore $DS -DiskGB 40 -NumCpu 2 -MemoryGB 8 -DiskStorageFormat Thick |
In the newest PowerCli version the error is more clear.
Add a -NetworkName or -PortGroup to fix the error.
Happy Automating 🙂
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:
|
1 |
Set-ExecutionPolicy -ExecutionPolicy Unrestricted |
If you want some kind of security and run only scripts from trusted publishers.
|
1 |
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned |
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.
There are multiple reasons why your minion did not return.
Hereby a couple checks you can do for troubleshooting your Salt – minion configuration.
On unix:
systemctl status salt-minion
On Windows:
Check it with services.msc
If not, add to dns or hostfile
On both master and 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
If you have other options then this, be free to comment 😊
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.
|
1 2 3 4 5 6 7 8 9 |
base: '*': - generic 'TST02 or TST0*2': - tst.win_generic #This match the following hostnames: TST02 and TST012,TST022,TST032 etc. #The SLS file in folder tst. |
Content of the win_generic.sls
|
1 2 3 4 5 6 7 8 9 10 11 |
tst_user: user.present: - name: TSTUser - groups: - Administrators - Users - fullname: TST Comod - password: {{ pillar['passwords']['TSTUser'] }} - enforce_password: False #More parameters: https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html |
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.
After importing a newer version of SQL Management pack, in our case (7.0.15.0). 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”
|
1 2 |
Import-module operationsmanager Get-SCOMManagementPack | where{$_.displayname -match "SQL server 2016"} | Remove-SCOMManagementPack |
There are multiple reasons for getting this event. It mostly happen when you restore a domain joined server or workstation.
Event details:
EventID: 5719
Source: NETLOGON
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.
ADDITIONAL INFO
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):
|
1 2 3 |
#Domain Credentials $cred = get-credential Reset-ComputerMachinePassword -Credential $cred -Server (DomainControllerFQDN) |
2. With netdom.exe using your Windows Command Prompt:
|
1 |
netdom.exe resetpwd /s:(domaincontrollerFQDN) /ud:(domainuser) /pd:(domainuserpassw) |
3. With the GUI:
Change your domain membership to WORKGROUP, reboot. And join again, reboot.
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:
|
1 |
sc queryex servicename |
Look for the PID.
Then
|
1 |
taskkill /f /pid PIDNR |
Or using PowerShell with a force command:
|
1 |
get-service | where{$_.status -match "stopping"} | stop-service -Force |
Recent Comments