Posts

Outbreaks such as Petya and WannaCry really put the malware threat on the IT agenda and made cybersecurity a priority for everyone. Fredrik Svantes, Senior Information Security Manager at Basefarm, explains the latest developments that keep the cybersecurity community busy.

https://blog.basefarm.com/wp-content/uploads/2018/02/wannacry.jpeg17862500Basefarmhttps://blog.basefarm.com/wp-content/uploads/2018/03/basefarm-logo-blue-1.pngBasefarm2018-03-23 12:45:232018-03-27 15:23:38Malware is so 2017: five new security trends to watch out for

If you, like me, manage many servers, it’s essential to name network adapters in a way that makes it easy to troubleshoot issues when they arise.

In complex networks with thousands of servers and all servers connected using multiple paths a consistent naming standard is very important!

PowerShell and the cmdlets available in Windows Server makes naming adapters a breeze. The servers we usualy deploy have built in four (4) port network adapters. We like to name the Windows NICs the same as is the default in Linux; eth0, eth1, etc.

In the following example we name the adapters eth0, eth1, eth2 and eth3 in Windows. The NIC with the lowest MAC address gets the name eth0 etc. (If you prefer to to start naming adapters from eth1 change the variable $NICs to 0):

Here at Basefarm we operate at a large scale with thousands of servers running for our customers. Quite often a customers asks for a list of machines with various properties for each machine.

Most of the time the customer want this information in an simple format so that they can use it internally. In this blogpost I will show how you can get the information about memory, CPU count etc for a set of Hyper-V machines from Virtual Machine Manager via PowerShell.

First off, start a PowerShell command line and load the PowerShell Snap-In for Virtual Machine Manager. Add-PSSnapin -Name Microsoft.SystemCenter.VirtualMachineManager

Now we can work with the commands made available to us by the Snap-In, if you want to find all the commands that are available issue: Get-Command -Module Microsoft.SystemCenter.VirtualMachineManager

So let’s begin by loading information about all our machines from the VMM host into a variable named $VMs $VMs = Get-VM -VMMServer hyperv-vmm01.sth.basefarm.net

What the above command does is to load all of the VMs on the host HYPER-V-01.mydomain.com into the variable $VMs. This means we will only do one call to the server which avoid generating unnecessary load.

Now let’s check how many machines we have: $VMs.Count

And now that we know we have machines to query, let’s find out what attributes exists (things we can get into our output) $VMs | Get-Member -MemberType Property

The above example adds some complexity to the command, but it is to filter so we only see machines that have the status is ‘PowerOff’.

Now let’s get what we wanted from the beginning, a list of machines for a specific customer. The list should include name of the VM host, VM name, memory, number of CPUs and current status. $VMs | where { $_.Name -Match 'CUST*' } | select VMHost, name , Memory, CPUCount , Status

This will list all machines who’s name begins with ‘CUST’. So we now have found what we wanted!

But instead of copying & pasting this we want to write the result to a CSV file so we can send that to the customer. Let’s make that easier by getting the output of the above command into a variable named $result $result = $VMs | where { $_.Name -Match 'LFO*' } | select VMHost, name , Memory, CPUCount , Status

Now our ‘report’ is stored in the $result variable and we can use standard PowerShell to export it to a CSV file: $result | Export-Csv -NoTypeInformation -Delimiter ';' .\report.csv

Now our report is available in a CSV file on the file ‘report.csv’ (in the current directory)

Working as a technician at a solution and hosting provider means that I often need to ask customers what parts of Windows they use. As soon as we meet a new customer we need to understand what parts of Windows they are using and what parts we need to setup in the customers environment in our datacenters.

The old way of doing this is by simply asking the customer. That’s fine but it tends to lead to copy & pasted lists of various pieces of information that really doesn’t make sense for our techies.

If we encounter customers that use Windows Server 2008 R2 it’s super easy. We can then use the power of the shell (PowerShell!) to inventory exactly what roles and features they have installed in their servers. We can ask the customer to run this in their environment:

We then ask the customer to send back the XML file. At our end we can now import the information we need:

$features = Import-CliXml computername-windows.xml

Once we have done that we can exactly see which features they have enabled on their servers.

https://blog.basefarm.com/wp-content/uploads/2018/03/basefarm-logo-blue-1.png00Joakim Westinhttps://blog.basefarm.com/wp-content/uploads/2018/03/basefarm-logo-blue-1.pngJoakim Westin2012-10-19 13:20:042013-08-15 10:07:48Getting the right features

Now that Windows Server 2012 will be officially available many servers will be installed as ‘core’ servers. That is in itself a very good thing. The bad thing about it is that Microsoft have set the default command Shell to be CMD.EXE. Nothing wrong with that per se but these days administrators should go PowerShell all the way. If you’re like me and want PowerShell to be your default shell even in core servers, do this to make PowerShell your default shell:$Path = 'Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\winlogon' Set-ItemProperty -Confirm -Path $Path -Name Shell -Value 'PowerShell.exe -noExit -Command Set-Location "$env:userprofile"

The next time you login to the machine you will get PowerShell as the default shell 🙂

As you can see this generates a password that is 10 characters in length and contains at least 2 non-alphanumeric characters. Now all I needed was to iterate this 1400 times and then output the result to the clipboard, simple as pie:

At Basefarm we frequently need to ensure that many Windows servers are identical in terms of the roles and features they have installed. Adding features can be done in a number of ways. Mostly the graphical userinterface (Server Manager) is used. Or for large operations System Center or similar. I will show you how this can be done more easily using the command line. This method doesn’t require anything beyond Windows Server 2008 R2 (or later) and PowerShell.

The Server Manager module

Using these is simple. Start a PowerShell session with administrative privileges (Run As…) . Then check that the Servermanager module is available in your server: PS C:\> Get-Module -ListAvailable

This shows that the Server Manager module is available on our server but that it is not yet loaded into the PowerShell session. To load it (and make its commands available):

PS C:\> Import-Module Servermanager

Now the commands of the Server Manager module are available to you. Check which commands are exposed by the module:

PS C:\> Get-Command -Module Servermanager

Ok, we’re all set. Let’s use these commands!

HOWTO: Document what is installed

To see what is installed in a server use:

PS C:\> Get-WindowsFeature

ooops, that’s a lot of text flying by on the screen! As you probably can guess only lines with [X] are installed. So we need to filter the list to only show what is actually installed, try this instead:

PS C:\> Get-WindowsFeature | ? { $_.Installed }

A nice clean list showing which features are installed on the server ;-), perfect for documenting your server(s)

HOWTO: Clone installed features to another server

As shown above it’s easy to list what is installed. But just having this list on the screen doesn’t make much sense, we need to be able to store this in a structured way so that we can use the list on another server to install the same features. PowerShell makes this very simple. We use the Export-CliXml cmdlet to save the information in a structured XML file:

HOWTO: Add features from another server (using XML file)

Now you have the same list of installed features on the new server. But… this is simply a list in memory and on screen. The features haven’t been added yet. In order to do that we need to pipe the information into the Add-WindowsFeature cmdlet.

Before I show you how to do that there is one important thing I need to explain. When we exported the list of installed features we included all features that were marked as installed. As you saw in the output this resulted in a tree like structure where “[X] Web Server (IIS)” was on the top followed by “[X] Web Server” and so on.

That looks fine but if we use this as input for the Add-WindowsFeature cmdlet we will end up with more than we asked for. The reason is that when the top level feature such as “Web Server (IIS)” is choosen everyting underneath it will also be installed. And in order to keep our servers a lean as possible we do not want this! We need to go back and filter the output of Get-WindowsFeatre a little more. Try this instead of what I showed you earlier: