Powershell – Check Free Memory script

 

Here’s a quick script I did using Powershell to check your free memory and report back the amount in MB and GB.

 

$freemem = Get-WmiObject -Class Win32_OperatingSystem

# Display free memory on PC/Server
"---------FREE MEMORY CHECK----------"
""
"System Name     : {0}" -f $freemem.csname
"Free Memory (MB): {0}" -f ([math]::round($freemem.FreePhysicalMemory / 1024, 2))
"Free Memory (GB): {0}" -f ([math]::round(($freemem.FreePhysicalMemory / 1024 / 1024), 2))
""
"------------------------------------"

Download the script here

 

The figure is determined and held in the $freemem variable. After that we simply output two lines to show the amount in MB and GB. We use a simple function to divide the figure by 1024 and round it off, displaying the result with two decimal places. The figure needs to be divided by 1024 as the variable holds the amount in Kilobytes (KB), therefore to determine Megabytes (MB), we divide by 1024. The second figure for GB requires one more division.

 

 

 

More PowerCLI basics – Host operations

 

On my quest to learn more about PowerCLI, I have been playing around with some more cmdlets in my lab. As a simple task, I have figured out how to tell ESX or ESXi hosts to enter and exit maintenance mode. Here’s how we do this. First of all ensure you are connected to your vCenter server instance using Connect-VIServer ServerName.

 

Enter maintenance mode:

Set-VMHost ESXi-01.noobs.local -State "Maintenance"

 

Exit maintenance mode:

Set-VMHost ESXi-01.noobs.local -State "Connected"

 

Set host to “disconnected” state:

Set-VMHost ESXi-01.noobs.local -State "Disconnected"

 

So now that we know the basics of setting the state of a VMware host, how about we get slightly more technical and perform one of the above operations on a bunch of hosts in one go? Powershell / PowerCLI is all about automation after all! Note that in the following script, I have also include a simple “if / else” statement to prompt the user running the script manually as we are about to send all ESX(i) hosts into maintenance mode! Use this at your own risk of course, it is just for demonstration purposes. You may want to modify to select hosts to enter maintenance mode on certain criteria. For example, all hosts in a particular cluster, or all hosts with a certain property. Here is the script I would use to perform the operation on all the ESX(i) hosts found in vCenter:

 

$VCServer = “yourvcservername”
Connect-VIServer $VCServer
$confirm = Read-Host “Are you sure you want all hosts to enter maintenance mode? (type yes to continue) “
if ($confirm -eq "yes")
{
	Get-VMHost | Set-VMHost -State "Maintenance"
}
else
{
	"Script aborted (you didn't confirm by typing yes)"
}

 

Once the script is executed, you should get a progress indicator whilst hosts are being dealt with. Afterwards you’ll get some output from each host listing its relevant Connection Status and statistics. Like so:

 

In the above example, we set some variables, and use some basic logic checking with an IF ELSE statement and an equal to (-eq) operator. We also see how to perform a few operations on ESX or ESXi hosts. I hope this helps anyone starting out with PowerCLI. Please do leave any comments, suggestions or improvements in the comments section!

 

PowerCLI – checking for snapshots on VMs and emailing the report back

Checking for any snapshots running on VMs in various clusters can be quite repetitive if done manually, looking through vCenter at each of your VMs. In the clusters I work with there are a LOT of VMs to check, and naturally I wanted to automate this process. Sure, I could rely on the vCenter alarms for snapshot size warning, but these are not completely reliable, as they only alert me when snapshots start growing large in size. I wanted something that would alert me to the presence of a snapshot regardless of its size. I therefore set about learning the basics of PowerCLI (as you can see in my last post) and searched around for some sample cmdlets that would help me retrieve a list of VMs with snapshots on them.

 

So here is the end result of running this snapshot checking script. It uses powershell cmdlets to generate an HTML email and sends it across to the address you specify. You will of course need to ensure you can connect out on port 25 for mail and have authentication on your mail server (or being sending from and to a domain hosted on your mail server (i.e. connecting to relay mail internally). Enter your mail server, to, and from details in the script to customise it. You’ll also need to authenticate with your vCenter server before running the script of course – you could use a cmdlet in the script to do this automatically. I have just been manually authenticating for now as I have not yet deployed this in production and have just been testing.

 

 

So here is the all important PowerCLI script!

 

#These are the properties assigned to the HTML table via the ConvertTo-HTML cmdlet - this is used to liven up the report and make it a bit easier on the eyes!

$tableProperties = "<style>"
$tableProperties = $tableProperties + "TABLE{border-width: 1px;border-style: solid;border-color: black;}"
$tableProperties = $tableProperties + "TH{border-width: 1px;padding: 5px;border-style: solid;border-color: black;}"
$tableProperties = $tableProperties + "TD{text-align:center;border-width: 1px;padding: 5px;border-style: solid;border-color: black;}"
$tableProperties = $tableProperties + "</style>"

# Main section of check
Write-Host "Looking for snapshots"
$date = get-date
$datefile = get-date -uformat '%m-%d-%Y-%H%M%S'
$filename = "F:\VMwareSnapshots_" + $datefile + ".htm"

#Get your list of VMs, look for snapshots. In larger environments, this may take some time as the Get-VM cmdlet is not very quick.
$ss = Get-vm | Get-Snapshot
Write-Host "   Complete" -ForegroundColor Green
Write-Host "Generating snapshot report"
$ss | Select-Object vm, name, description, powerstate | ConvertTo-HTML -head $tableProperties -body "<th><font style = `"color:#FFFFFF`"><big> Snapshots Report (the following VMs currently have snapshots on!)</big></font></th> <br></br> <style type=""text/css""> body{font: .8em ""Lucida Grande"", Tahoma, Arial, Helvetica, sans-serif;} ol{margin:0;padding: 0 1.5em;} table{color:#FFF;background:#C00;border-collapse:collapse;width:647px;border:5px solid #900;} thead{} thead th{padding:1em 1em .5em;border-bottom:1px dotted #FFF;font-size:120%;text-align:left;} thead tr{} td{padding:.5em 1em;} tbody tr.odd td{background:transparent url(tr_bg.png) repeat top left;} tfoot{} tfoot td{padding-bottom:1.5em;} tfoot tr{} * html tr.odd td{background:#C00;filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='tr_bg.png', sizingMethod='scale');} #middle{background-color:#900;} </style> <body BGCOLOR=""#333333""> <table border=""1"" cellpadding=""5""> <table> <tbody> </tbody> </table> </body>" | Out-File $filename
Write-Host "   Complete" -ForegroundColor Green
Write-Host "Your snapshot report has been saved to:" $filename

# Create mail message

$server = "yourmailserveraddress.com"
$port = 25
$to      = "youremailaddress"
$from    = "youremailaddress"
$subject = "vCenter Snapshot Report"

$message = New-Object system.net.mail.MailMessage $from, $to, $subject, $body

#Create SMTP client
$client = New-Object system.Net.Mail.SmtpClient $server, $port
# Credentials are necessary if the server requires the client # to authenticate before it will send e-mail on the client's behalf.
$client.Credentials = [system.Net.CredentialCache]::DefaultNetworkCredentials

# Try to send the message

try {
    # Convert body to HTML
    $message.IsBodyHTML = $true
    $attachment = new-object Net.Mail.Attachment($filename)
    $message.attachments.add($attachment)
    # Send message
    $client.Send($message)
    "Message sent successfully"

}

# Catch an error

catch {

	"Exception caught in CreateTestMessage1(): "

}

 

Another point worth mentioning – you should change the path that the report is saved to on disk – in my script it is set to F:\, so just modify this to suit your environment. Kudos to Andrew at winception for his Snapshot checking code – I have used a lot of it above, but modified it somewhat to include additional information, and style the HTML table so that it is much easier on the eyes. I also added the e-mail functionality to the script. The following is a screenshot after I executed the script in PowerCLI manually. You would of course look to automate the process by scheduling this script in on your machine.

 

 

Enjoy, and please drop any comments, improvements or feedback in the comments section!

A quick way of finding out where your FSMO roles reside

 

A nice and simple blog post today, based on finding out where your FSMO roles lie, using just the command prompt. This is useful in a couple of different situations, namely:

 

  • You don’t want to spend a long time using MMCs / Active Directory Users and Computers to figure out where each of the FSMO roles are.
  • You don’t have easy access to MMCs – for example you are using Windows Server 2008 Core

 

This command works on both Windows Server 2003 as well as Server 2008 / R2.

Simply type the following in your command prompt window on one of your domain controllers:
netdom query fsmo

 

Your output should be something like the following, listing the servers which hold each FSMO role.

VMware, Coreinfo and mapping logical CPU cores to physical processors.

Sometimes you may have a requirement due to licensing to ensure a Virtual Machine’s CPU configuration is perfectly set out in terms of “physical sockets”. Or perhaps you want to run an operating system such as Windows Server 2003 SE on your Virtual Machine. By default this VM would be limited to only use 4 cores because of the way VMware tells the operating system that each CPU has only 1 core per socket. (Giving it 4 x vCPUs would be the same as giving a physical Windows Server 2003 SE machine 4 x physical CPUs – the actual CPU limit). Either way, it can be quite useful to verify you have the correct CPU configuration.

Enter Coreinfo. This is a handy command line utility by Mark Russinovich which allows you to dump the information about your current CPU and cache configuration for Windows. Download the utility and execute the following command to gather information about the logical CPU core mapping to physical processor.

coreinfo.exe -c -s

In the case of a single socket, six core CPU (such as the one I have running here) this is the output you will see:

 

The Logical to Physical Processor Map information in the first section marks each CPU core with an asterisk (*). The next section, lists the Logical Processor to Socket mappings, indicating how many “processor sockets” your machine has and at which location each Processor Core is at (again marked with an asterisk).

 

If you had provisioned a VM with 4 x vCPUs by default, this would show up with 4 x Sockets and 4 x Physical Processors like so:


Besides being a limiting factor for Windows Server 2003 SE VMs when trying to use 8 x vCPUs (you can’t have more than 4 x “physical” CPUs), this may also be a potential issue with a socket licensed edition of SQL server for example, as you would now have 4 x sockets to worry about with your licensing.

 

So here is where VMware’s useful extra configuration parameters come in handy. These are basically bits of extra configuration you can add to your VMs, and are stored in your VM’s .vmx configuration file. By simply editing your VM, you can add a configuration option which specifies how many Cores per Socket there are. To do this using vSphere, power off your VM, then edit it’s settings. Go to the Options tab, then General, then Configuration Paramaters.

 

 

In this case I have a VM with 4 x vCPUs, which shows up by default with 4 x processor sockets. I want this to be 4 x cores with 1 x socket. So now I would click “Add Row” and in the first empty column, enter: cpuid.coresPerSocket and use 4 as the value in the second column. See this screenshot for specifics (and adjust the value used depending on your desired configuration):

 

 

Power up your VM, and run coreinfo again, using

coreinfo.exe -c -s

 

You should now see that VMware is assigning 4 CPU cores per “Physical CPU socket”. In other words, your VM now has 1 x “physical” processor socket, and 4 x cores. Meaning your single processor application socket is now valid on this VM. Here is the result of assigning my VM a value of 4 for “cpuid.coresPerSocket” when it uses 4 x vCPUs in vSphere:

 

 

As you can now see, it has changed from the original configuration where it had 4 x Sockets listed under “Logical Processor to Socket Map” with a “Physical Processor” for each “Socket”, to showing the 4 x “Physical Processors” all on “Socket 0”.

 

If you are using VMware Workstation, this configuration is easy to do – just edit your VM settings, and look for the dropdown menu under the CPU configuration – change this to how many Processors you want and how many Cores per Processor you will use. (See the screenshot below for an example of 2 x Sockets with 2 x cores per socket):

 

 

Well, that is a brief overview of how to look at your Processor configuration (whether you are using a physical machine or a Virtual Machine), and how to change your CPU socket / core configurations using VMware vSphere or Workstation. The two uses I can think of as stated above are for licensing issues, or issues where you are being limited by what your guest OS can handle in terms of physical CPUs. Feel free to chime in, in the comments below if you can think of any other uses this may have, or if spot a mistake anywhere!