Unable to install Powershell modules

Installing powershell modules from powershell gallery on a machine with no direct internet access but which has access via a proxy just needs the proxy url / credentials supplied on the install-module command.

e.g. install-module vmware.vim -proxy http://<proxyip>:<proxy port>

However if you have no repositories registered with Powershell (such as the powershell gallery) you may still see errors relating to the NuGet provider:

NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet

 provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or

'C:\Users\administrator\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by

running 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install

and import the NuGet provider now?

And when attempting to install nuget, even specifying a proxy you may still get errors because the repository isn't registered.

The solution is to register the default repository via proxy, which will then allow modules to be installed

PS C:\> Get-PSRepository

WARNING: Unable to find module repositories.

PS C:\> Register-PSRepository -Default -Proxy http://<proxy ip>:<proxy port>

PS C:\> Get-PSRepository

Name                      InstallationPolicy   SourceLocation

----                      ------------------   --------------

PSGallery                 Untrusted            https://www.powershellgallery.com/api/v2

You should now be able to install modules via the proxy with the -proxy parameter

Error after docker upgrade: "docker: Error response from daemon: OCI runtime create failed"

After upgrading docker and docker cli (CentOS 7), a previously working container decided to bomb out with the following error: 

docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"write /proc/self/attr/keycreate: permission denied\"": unknown. 

 It turns out that container-selinux also needs to upgraded to match.  

e.g. run yum upgrade docker-ce.x86_64 docker-ce-cli.x86_64 container-selinux 

Importing DFSR debug & Event logs info vRealize Log Insight

If you're running a large DFS replication cluster with a large (millions) number of files, you probably have a very high turnover of both Windows Event logs and DFSR debug logs.

There are many log aggregation tools, from the freeware ELK stack and Greylog to the paid for Splunk and vRealize from VMware.  The vRealize Log Insight tool doesn't have the per GB licencing model that Splunk has, but also comes up a little short on functionality in the way of pre-built "apps".

Neither have an app for DFSR but luckily it doesn't take much in Log Insight to import the DFSR logs.  It's also (OVA) appliance based, so to add capacity you just deploy another appliance and join it to the cluster.

To import the DFSR logs you need to deploy the Windows Log Insight Agent to the file servers in question.

msiexec SERVERHOST=<log insight ip> /qn /i <agent msi filename>

Then once the agents are reporting into Log Insight, go to the administration page and choose management->Agents. Create a new group containing the File servers and enter this configuration

[filelog|DFSR_logs]
directory=C:\Windows\debug
include=Dfsr01000.log
event_marker=^\d\d\d\d\d\d\d\d\s\d\d:\d\d:\d\d.\d\d\d

[winlog|DFS_Replication]
channel=DFS Replication
tags={"ms_product":"activedirectory"}
parser=auto

This will ensure the DFSR debug logs are imported in multiline format as a datestamp is applied at the start of every new record.

Using Powershell values from the start of the pipeline in a table at the end.

There are two ways to deal with large arrays of nested objects in powershell.

One is a bunch of nested foreach loops which is nicely readable in scripts.

However the beauty of the pipeline is that you can run output from one command into the input for another, which is often the way to drill down into dependent objects.

One such example is Vmware portgroups in Powercli.

The hierachy can be several levels deep

e.g.

cluster
 -> host
   -> vswitch
      -> portgroup

I wanted to build a table showing portgroups on all hosts in a cluster, ignoring the default management kernel port

The command is quite simple.

Get-Cluster -name Cluster01 | Get-VMHost | Get-VirtualSwitch -name vSwitch0 | Get-VirtualPortGroup | where {$_.name -ne "Management Network" | select Name, VirtualSwitch | ft -autosize

This produces a nice table showing the portgourp name and the vswitch it's connected to.

However the hostname isn't a property of the portgroup, it's a property of the vswitch (or the host) so the question is how to show it in the table.

The answer is with the pipelinevariable command (introduced in PS4 and above) and a custom property expression.

Get-Cluster -name Cluster01 Get-VMHost | Get-VirtualSwitch -name vSwitch0 -PipelineVariable 'fi' | Get-VirtualPortGroup | where {$_.name -ne "Management Network"} | select Name, VirtualSwitch, @{Name = "VMHost";Expression = {($fi.vmhost)}} | ft -AutoSize

This returns a nice table of three columns, with the third column

Error scanning Dell hosts with VUM "Host cannot download files"

This is one possible solution for the error "Host cannot download files from VMware vSphere Update Manager patch store. Check the network connectivity and firewall setup, and check esxupdate logs for details"


If you're running Dell hosts and Openmanage, there is an issue with the Openmanage VIB 8.2.0 - 8.5.0 (possibly other versions but these are the ones I've tested).

Unzip the file and have a look at the index.xml file



In my case the line containing the tag had a typo - you'd have thought Dell could spell their name, especially when it's only 4 characters long. 

Edit this to be Dell and re-zip the files (making sure the files are in the root of the zipfile)

 
 

The bad news is that you can't manually remove VIBs from the VUM database once they've been imported, so you basically have to nuke your VUM config so first make a note of all your baselines / baseline groups.

At least you no longer have to uninstall and reinstall the database - there is a tool called VMwareUpdateManagerUtility.exe in the Update Manager application folder which will reset the database.  Run it, point it at your VUM server, login and choose the Database settings -> re-initialize database option:





You should now be able to re-import the new VIB zipfile and perform a scan.

Unfortunately if you have alot of baselines or baseline groups, you'll need to recreate them.

Cannot create KDS Root Key - “Request is not supported”

When trying to run the powershell command Add-KDSRootKey –EffectiveImmediately you get the error "Request is not supported" if the powershell console isn't running elevated as administrator.

Just right click on the powershell icon and run as administrator and rerun the command.

V2V error with vConverter standalone - Unable to obtain hardware information for the selected machine.

When converting a VMWare workstation format VM (V2V) you might get this error if you're trying to read the image from a network path with a deep folder structure.

The simple resolution is to map a drive letter at the top level so the vmx and vmdk files are visible directly under the drive letter.

The converter wizard will then allow you to progress to specifying the destination system.