SCCM Site Code Change with PowerShell

I came across a case whereby a test SCCM installation had been completed and needed to be removed and replaced with a production instance. There are a few cleanup operations but in this case I needed to automate a way to change the clients to point to the new Site Code.

This can be completed with the below PowerShell command replacing SITECODE with the new Site Code (PowerShell run as administrator)


Running across VM’s in vCenter

I also have a script for completing in PowerCLI by using the Get-VM command, this is broken down below.

This presumes you have already created a connection to your vCenter through PowerCLI

*Use PowerCLI x86

#Get vm name and check if it exists within vCenter, loop until true

$Name = Read-Host "Enter the Name or Names using wildcard * of the VM e.g Server*"
$VM = Get-VM $Name | Where {($_.Powerstate -eq 'PoweredOn')}           
   IF ($VM){
                  $Isname = $True
                  Write-Host "VM FOUND :)" -Foreground GREEN
                  } ELSE {
                  $Isname = $False
                  Write-Error "VM NOT FOUND! :(" -Background RED -Foreground Black
}UNTIL ($Isname -ne $False)

Note that there is no error checking on the below, replace the GuestUser and GuestPassword parameters with your own credentials with administrative rights on the VM Guest OS.

#Run script in Guest

Write-Host "Running Script..."

$ScriptText = "PowerShell.exe -NoProfile -Command ""([wmiclass]'ROOT\ccm:SMS_Client').SetAssignedSite('GSY')"""

Invoke-VMScript -VM $VM -ScriptText $ScriptText -ScriptType bat -GuestUser administrator -GuestPassword *Password*

In the perfect world this environment would have WinRM enabled across the server estate but alas it didn’t. This saved a fair amount of manual work for me and I hope it does you too!

Complete script available here –> SCCMSiteCodeChange just paste into PowerShell ISE, save and run from PowerCLI.

SCCM Update Download Error 0x80070005

Today I came across an issue with updates which were unable to download from an SCCM Distribution Point. Further investigation pointed to the fact that the Content Transfer Manager log located under C:\Windows\CCM\Logs\ contained error code 0x80070005 relating to ACCESS DENIED.


Pasting one of the URL’s of an update from the Content Transfer Manager Log into the browser confirmed that indeed access was denied to that content.




Opening IIS on the SCCM Distribution Point it was noted that no authentication was specified on the sub-sites as below. On this particular instance Windows Authentication was missing and the only options were Anonymous Authentication or ASP.NET Impersonation.


We could enable Anonymous Authentication to resolve this issue but in terms of security that would not be best practice. If like this instance Windows Authentication is missing (it appears as though the SCCM installation of a DP will continue if Windows Authentication is missing) you will need to enable this in Server Manager under the feature Web Server/Security as below.


Restart IIS and enable Windows Authentication on both the SMS_DP_SMSPKG$ and SMS_DP_SMSSIG$ sub-sites of the Default Web Site.

Updates downloading and installing successfully!



WD NAS as VMware NFS Datastore

I came across a use case for using a Western Digital MyBook Live as a VMware NFS datastore, I’m fairly sure this can be completed on similar devices with a bit of configuration.

This initial task is to access the shell of the WD MyBook, this can be completed by accessing the ip or hostname of the device through the web url as documented here, below is a quick reference.

  1. Login to the URL of WD MyBook http://ipaddress, if address is unknown, try using DHCP to find a reservation
  2. Change the URL to http://ipaddress/UI/ssh
  3. Tick active SSH

Next you will need to create an SSH session to the IP address of the WD MyBook in this case I am using putty, the default credentials are below:

username: root 

password: welc0me

We then need to create the NFS share and configure the permissions for the share (thanks to Falco Timme).

  1. Type su and hit enter to raise the rights to sudo “admin”
  2. Type the command mkdir /nfs/sharename/ where sharename is the name of your share.
  3. Enter vi editor to edit the exports file with the command vi /etc/exports (This is to configure the share permissions)
  4. Edit the file as shown below replacing the 192.168.X.X with the IP of the ESXi host (deleting the other lines from the file will stop the web interface from working), i for insert (use the arrow keys to navigate, :wq! to save and exit, :q! to exit without saving. Excellent Vi Editor tut here. *Add additional entries for extra hosts*2015-09-14_23-41-53
  5. Type the command exportfs -a hit enter and type reboot, hit enter to complete.

We now need to map the NFS drive in ESXi as below:

Via VI Client

  1. Open a vi client to the ESXi host and select the Configuration tab
  2. Select Storage on the left and Add Storage on the right
  3. Select the option Network File System and click Next
  4. Enter Server hostname or IP, folder as /nfs/sharename and give the datastore a name, click Next2015-09-16_22-49-54
  5. Select Finish to complete

Via ESXi Shell

  1. Create putty session to ESXi Host
  2. Enter the command esxcli storage nfs add -H hostnameorIP -s /nfs/sharename -v datastorename and hit enter.2015-09-16_23-10-12

I will be attempting the same with a Buffalo Link station in the coming weeks but its food for thought in terms of a reuse for cheap ESXi NFS Storage!

VMware vCenter SRM 5.5 Database Configuration

I was repairing an issue with connectivity between a primary vCenter and secondary vCenter site and their SRM Servers when I came across a configuration on both SRM databases which was not ideal. Both SRM users had sysadmin rights on each SQL Server.

I have seen many installations whereby the privilege of sysadmin has been given to a SQL Security login account, this being the case in this instance. Best practices for a secure environment is to limit this activity as much as possible.

According to the installation documentation the database schema must have the same name as the database user account among other things.

Database schema:

  • The Site Recovery Manager database schema must have the same name as the database user
  • The Site Recovery Manager database user must be the owner of the Site Recovery Manager
    database schema.
  • The Site Recovery Manager database schema must be the default schema for the
    Site Recovery Manager database user.

I would advise making individual AD accounts during the installation of SRM, the procedure below outlines the database configuration. (Thanks to our DBA for the assistance).

Create your security account as you normally would do, e.g DOMAINNAME\SRMSERVICE

Ensure that the service VMware vCenter Site Recovery Manager Service on the SRM servers are also running as the DOMAINNAME\SRMSERVICE user. I have noticed this gets set back to local system if you run the modify wizard on an existing installation.


Ensure Default Database is set to the SRM Database. Select the SRM Database and select

New Query and type the below command, click execute.


This maps the security login DOMAINSERVICE\SRMSERVICE to the dbo database user account, as seen if you open the SRM database user account “dbo”.


Complete the same on both the SRM primary and secondary databases and on each primary and secondary SRM server restart the VMware vCenter Site Recovery Manager Service.