Many of you are probably familiar with the new Reboot Behavior Policy. Maybe you’ve scratched your head trying to figure out why the Citrix policy didn’t work. Maybe you’ve spent a whole day until you came upon this blog post telling you that the Reboot Behaviour Policy only works with Enterprise or Platinum license. Thanks for letting us figure it out the hard way Citrix!

Some of you may also have tried Citrix Power and Capacity Management finding out that it needs a similar license, its own database and control server. Kind of overkill for small SMB environments with only 10-50 servers.

A couple of weeks ago I stumbled upon a superb Citrix XenApp Rolling Reboot Script created by Dane Young. The script supports XenApp 5-6.5 and basically it uses a Load Evaluator to drain servers one by one. Once all sessions have been logged off, the server will go down for a reboot.

The script will also validate that the last rebooted server was successful before continuing on to the next server in the farm. By implementing this script in your organization you’ll get a zero-downtime 24/7/365 system without the annoying “Please Log Off” messages.

We’ve been running this script successfully for a couple of weeks with great success. Right now we’re having a dialog with Dane Young to add more features and further improve the script e.g. adding the possibility to create an Exclude Servers list to the Citrix XenApp Rolling Reboot Script.

In Citrix XenApp 6.5 there’s now also a great new feature called Logon Control that will let you drain servers without adding any form of Load Evaluator.

Resources :

• Citrix XenApp Rolling Reboot Script
• Citrix Reboot Policy

Very often we (the Ask the Architects team) are asked which optimizations should be applied to a XenApp (6/6.5) server. What we typically do to answer that question is to dig through our personal knowledge repositories and try to come up with a good list of tweaks. Well, that is not exactly a very efficient process so we though it’s now time to comprise a comprehensive guide, that summarizes the most common optimizations.

Unfortunately there is a myriad of registry tweaks or GPO settings that can optimize a Windows Server, but many of them are related to very specific scenarios only and have the ability to actually limit the scalability in other cases. So we basically filtered out those “toxic” tweaks and summarized only the optimizations that apply to many (if not all) environments. Nevertheless it is important to test every change in detail before rolling it out to production. So please keep that in mind. Always!

The new guide (which can be downloaded here) is split into two sections.

• Section 1 – Windows 2008 R2 Configurations: This chapter focuses on optimizations that are applied at the server level. We have split the chapter into general optimizations for XenApp servers and optimizations for XenApp servers which are provisioned by means of Provisioning Services (PVS). Furthermore we took a look at services as well some file server optimizations.
• Section 2 – User Settings: This chapter focuses on user specific optimizations, which also includes a few XenApp Policy tweaks.

As mentioned earlier we tried to include common optimizations only. So there is a long list of things we skipped on purpose because of the aforementioned reasons. But in case you know an RegKey or GPO setting that we have missed out, please leave a comment or send me a mail and I’ll incorporate it into the guide.

Update: The Optimization Guide has also been added to the XenDesktop Design Handbook. You can find it within the Planning Guides section.

Teradici is releasing today a new version (3.5.0) of the PCoIP Zero Client firmware. This new version provides major security and functionality enhancements. Teradici itself is calling it the biggest PCoIP release to this data.

• Imprivata OneSign authentication – Secure single sign-on authentication facilitates increased productivity for roaming desktop users
• Improved USB transfer rates with VDI (USB2.0) – Users can expect to see up to 3X improvement in transfer speeds
• 802.1X network authentication – PCoIP zero client devices can now be deployed with the highest degree of 802.1X security using EAP-TLS certificate-based authentication.
• IPv6 support – PCoIP zero clients updated to support ongoing mandates for IPv6 adherence.
• “Help Desk” mode – Administrators can enable an OSD login screen link which allows users to log in to a particular VM of the administrator’s choice. This VM may be configured by the administrator to provide specific support directions for users
• Support for up to 25 View Connection Server addresses – Adds additional flexibility and scalability for large enterprises.
• 100BASE-FX – Support for fast Ethernet over optical fiber for enhanced security over long distances

Along with the new features Teradici is also releasing a new version of the PCoIP Management Console, version 1.7.0.

Note that the enhancements are only available for the hardware based Teradici PCoIP Zero client. The soft version provided by VMware with VMware View does not currently support the enhancements above.

Imprivata OneSign authentication

According to my previous experiences many organizations, specially healthcare providers, have been waiting for the ability to utilize Imprivata SSO with with tap of a proximity card with zero clients to enable true follow me virtual desktop roaming.

Improved USB transfer rates with VDI (USB2.0)

The USB 2.0 Compatibility support is also a huge plus for VDI users. Teradici told me that users can expect to see up to 3x improvement in transfer speed for bulk transfers (read and write) when compared to earlier PCoIP zero client firmware releases (which supported USB 1.1 transfer speeds with many USB 2.0 devices). This means up to 18Mbps may be achieved, but the results may vary for different USB devices and under different network conditions.

802.1X network authentication

802.1X is an IEEE Standard for port-based Network Access Control (PNAC) and adds an additional layer of security on top of usernames and passwords, particularly for sensitive network environments. EAP-TLS (certificate-based) is supported – which is the most secure method of 802.1X authentication.

1. Supplicant sends certificate to Authenticator (ie network switch)
2. Authenticator forwards certificate to Authentication Server for verification
3. Authenticator grants or denies network access based on response from Authentication Server.

In a following post I will explain how to setup the Imprivata OneSign authentication. However, the new firmware is already available for download at Teradici Support website. Go to www.teradici.com for more Information.

When implementing a Provisioning Services infrastructure the decision about the Write Cache location is one of the most important and therefore one of the most discussed. As I already wrote two blogs about this topic (you can find them here and here) I’ll not bore you with any more theory. Instead this time I’d like to share some practical real world data, of an environment where the PVS Write Cache of 6 virtual XenApp servers is written to the local disks of a single XenServer. This configuration is discussed quite often as it is a very cost effective solution (Alex Danilychev wrote a nice blog about it), but it also holds the risk of the local disks being a bottleneck. So in order to understand whether this configuration works for your environment as well, you need to perform some in-depth testing and analysis. Check out CTX130632 for some guidance.

For the customer in my example this configuration works pretty well, since about 3 years now. Initially the customer has chosen this configuration for cost reasons, as a configuration with shared storage would have required them to upgrade the SAN controllers in addition to adding a large number of disks to the existing shared storage infrastructure.

The Environment

- All XenApp servers are virtualized using XenServer 5.6 SP2

- Rack-Mounted HP 2U Servers

• 4 x 140GB 15k SAS disks
• Smart Array P410i – RAID Controller
• 512MB Battery Backed Write Cache
• RAID 5

- Running XenApp 6

- 30 concurrent users per XenApp server during the office hours

- More than 1.500 concurrent users in total

- Ratio of 6 XenApp servers per XenServer Host

Gathering the Performance Data

We gathered the performance data using the standard Linux command iostat. In order to filter out the unnecessary data right away we piped the output into the awk command. This gave us the following command string:

“iostat -xk 15 5760 | awk ‘BEGIN {print “Time Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util”} /c0d0/ {print strftime(“%H:%M:%S”),$0}’ >iostat.csv”

In detail this command means:

- iostat –xk 15 5760 – Runs iostat with extended statistics (in KB format) at a 15 second interval 5760 times (= 24 hours)

- /c0d0/ – Filters the output for block device c0d0

- >iostat.csv – Writes the iostat output into the file iostat.csv

After running this command we got back a 1MB csv file which could be imported into Excel. From there it was pretty easy to create the following graphs (please note that we captured the data over night, so the middle of the graph is midnight):

The Performance Graphs

The first graph show shows the IOPSs caused by the PVS write cache activity of the virtual XenApp servers. As we can see the majority of the IO activity is writes, which is the same within virtual desktop environments. (Please click on the graphs to enlarge them)

The second graph shows the read write ratio in even more impressive detail.

The third graph shows the throughput in Kbyte/s. So this is the actual amount of data that is read and or written:

Finally we need some data to put the graphs into a relation. So here is the utilization chart of the local disk subsystem:

As we can see the disk subsystem is nowhere near its saturation, although it has to handle more than 800 I/Os per second during the peak logon period. This is only possible because the RAID controller has been equipped with battery backer write cache. This allows the RAID controller to commit the write operation back to the XenServer almost immediately. The actual write to disk is performed whenever utilization permits. While I don’t have any data without such a cache, I’d assume we would see a utilization of at least 90% if not even higher.

Maintenance approach

I’m sure some of you will ask now how does the customer do hardware / hypervisor maintenance and how do they cope with outages? The reason behind this question (for those who couldn’t follow) is that in such a configuration the virtual XenApp servers are tied to an individual XenServer. This is because the virtual disk attached to the virtual machines cannot be moved. So a XenMotion is not possible and if the XenServer needs to be powered down all resident VMs need to go down as well. The customer solved this issue with a very pragmatic approach. The just bought two XenServers more than required to hold 100% of the load. So in case of any maintenance work they just disable the logons of the respective XenApp servers. When the last user has been logged of, they are able to do whatever needs to be done without impacting any user. Of course this is not as flexible as using XenMotion, but given the cost savings mentioned earlier it was ok for them to have that level of “in-flexibility”.

Customer happiness

Besides showing the pure technical metrics it is very important answer if the customer is happy with this configuration. Basically the answer I got was “Yes, we’re happy with this configuration and we would recommend this solution other customers as well. But of course this depends on the requirements of the individual environment”.

So I think this shows that a PVS write cache on local disks configuration is a valid solution for XenApp environments, that not only works in theory. I would like to prove the same for a XenDesktop environment, but I could not get my hands onto some real world data where I also got the permission to publish it. So in case you would like to help me here, please leave a comment below or mail me directly.

In my previous article I focused on FAST Cache benefits for VDI deployments. The tests I completed also generated a huge quantity of data that is tremendously valuable for better sizing of VDI environments.

I previously have discussed how IOs suffer severe split between replica, linked clone and persistent disks. Depending on the storage tier serving the data it is possible to have different latencies for different parts of the Guest OS (Windows XP or Windows 7). However, in a linked clones environment the disks are interdependent at GuestOS layer, and a VMDK suffering from latency will also affect a different VMDK that is not suffering. Example: Replica disks that are backed by Flash Drive drives with Linked Clones that are backed by SATA drives.

In my validation with 200 VMs during Steady State each VM has an average of 8 IOPs. The 8 IOPS per virtual desktop is split into 0.29 IOPs for the Replica and 7 IOPs for the Linked Clone.

This represents 4% read-only operations for the replica and 96% read/write operations for the Linked Clone.

These numbers clearly identity that during Steady State the Replica disks are barely used and most of the IOs are absorbed by the linked clones. The two graphs below demonstrate the IO split between replicas and linked clones.

With knowledge of the disk behavior it is possible to size storage for the exact performance required in each tier.

VMware recommend placing Replicas disks in a Flash Drive (SSD) tier. However, you know now that Flash drives would only really be effectively used out of the Steady State period.

On the right picture (above) two spikes are clearly observed. The first is the logon storm; the second is the VMware View Refresh operation storm. Those are the periods when the Replica disks are utilized more aggressively. However, Linked Clones are equally utilized.

In fact, Linked Clones disks are more comprehensively utilized than the Replicas. This actually makes me evidently think that if there is a limited number of Flash Drives to be utilized they should be supporting Linked Clones, not Replicas. Most recent intelligent storage arrays will cache most utilized blocks in L1 DRAM cache, and if the Replica disk is being heavily utilized those blocks will end up in cache anyway.

It all comes down to how the VDI environment is utilized by the users. If boot storms, logon storms and VM refreshes are often requested, such in a Non-Persistent Pool serving school classes, then it is important to support Replica disks as much as possible. That means Replica disks should be on the fastest storage tier.

If there are no constant VM refresh or extreme login storms, then it is probably it is better to support Linked Clones as much as possible. That means Linked Clones should be on the fastest storage tier.

I know, I know… that goes against industry recommendation. Well, I guess there is always someone to go 1^st against the flow. I have done my tests and math and I recommend you to do yours.

Of course, if your organization have budget to employ Flash Drives for everything, go for it! There are technologies on the market that help in reducing the number of disks required to serve a larger number of IOPs without having to utilize an all SSD based array. Find out more here.

Kyle Gleed, Sr. Technical Marketing Manager, VMware

For folks who are still running the classic ESX hypervisor there is a new fling available to help smooth your migration to ESXi.  The ESX System Analyzer scans existing ESX hosts looking for issues that could affect your transition to ESXi.  It produces a nice report that you can use to assess your readiness and identify any potential risks that you should be aware of before moving to ESXi.  Check it out, I think you'll like it. 

Hi everyone, Madelinde here.  Since the release of the Dynamics AX 2012 client, we have received a couple of issues when customers try to virtualize this new client using Microsoft Application Virtualization 4.6 Service Pack 1. Earlier versions of the AX client did sequence properly.

This post describes the symptoms, the resolution and the workaround for this particular issue.

The symptoms

When you try to sequence the Dynamics AX 2012 client with the App-V 4.6 Service Pack 1 sequencer on Windows 7 or Windows 2008 R2, you will notice that the Sequencer crashes with the below error.

SFTSequencer.exe – Application Error

Message: The instruction at 0x77bc76e6 referenced memory as 0xfce7687b.
The memory could not be read.
Click OK to terminate the program.

The sequencing will fail and you will be unable to sequence the new AX 2012 client.

This problem is caused by an issue in the App-V Sequencer. On Windows 7 and Windows Server 2008 R2, a specific function works different than on previous Windows versions such as Windows Vista. This issue will be addressed in a future Service Pack for App-V 4.6.

In the meantime, there is a workaround available that will allow you to sequence the AX 2012 client without issues. As mentioned before, the issue happens due to the behavior of a function in Win7/2008R2 only. Because the function behaves differently on Windows Vista, the issue will not happen on this OS. Therefore, if you follow the steps carefully, you should be able to sequence the application on Windows Vista. This package should work as expected on Windows 7 and 2008 R2.

IMPORTANT NOTE: Normally, App-V is not a cross platform solution. In this specific case the package will work because we have no platform specific things to consider. Therefore keep in mind that other applications will not work.

The workaround

The workaround for the issue is to sequence the AX 2012 Client using the following steps on a Windows Vista x86 or x64 machine instead of Windows 7 or 2008 R2.

When following the steps carefully on a Windows Vista machine, we should be able to sequence the AX 2012 Client with App-V 4.6 Service Pack 1.

Follow these steps first before you start the Sequencer:

1. Disable the "Windows Presentation Foundation Font Cache 3.0.0.0" Service

2. Disable the "Windows Presentation Foundation Font Cache 4.0.0.0" Service

3. Launch the AX Setup.exe; install all AX Client component prerequisites (use AX setup "Validate prerequisites" to assist in this).

4. Reboot the virtual machine and make a snapshot.

Workaround for AX setup problem:

1. Launch a command prompt.

If installing AX from a CD/DVD drive, change directories to the root of the CD/DVD drive.

If you are installing from the network share, you must map a network drive to the share, then change directories into the folder that contains AX's setup.exe

2. Launch the App-V sequencer from the command prompt:

"C:\Program Files\Microsoft Application Virtualization Sequencer\SFTSequencer.exe"

This will make the Sequencer's working directory the directory where AX's setup.exe exists.

The Sequencing process:

1. Start the App-V 4.6 Service Pack 1 Sequencer.

2. Click "Create a New Virtual Application Package".

3. Click "Next" (Create Package)

4. Address any issues that are reported on the "Prepare the computer for creating a virtual package" screen and click "Next".

5. Click "Next" (Standard application package).

6. Browse to the installer (AX's setup.exe).

7. Set Virtual Application Name to "AxClient" and then click “Next”.

8. This will launch the AX setup.

9. Click "Install Dynamics AX components".

10. Click "Next" on the "Welcome" screen

11. Accept the license terms and hit “Next”

12. Pick whether or not to join the Customer Experience Improvement Program and hit “Next”

13. On the “Set a file location” screen, choose “Q:\AxClient” as the File location (same folder as was chosen from the Sequencer UI)

14. Click OK to the dialog about placing install files in a different location.

15. Hit “Install” on the “Ready to install” screen to install the Setup Support Files

16. Hit “Next” on the “Select installation type” screen (Custom installation is the only choice)

17. Click the "Client” checkbox in the tree "Prerequisite Validation" should be all successful, hit "Next".

18. Check "Create a desktop shortcut for Microsoft Dynamics AX client application" on the "Select client preferences" screen, hit "Next".

19. Hit Next on the "Specify a location for configuration settings" screen.

20. Enter the required information on the "Connect to an AOS instance" screen, hit "Next".

21. "Prerequisite Validation" should be all successful, hit "Next".

22. Click "Install" on the "Ready to install" screen.

23. Install should succeed, push "Finish".

24. Click the "Exit" button on the AX Setup window.

25. Check the "I am finished installing." checkbox and hit Next.

26. The Sequencer will process for a minute.

27. On the "Configure Software" screen, select "Ax32.exe" and click "Run Selected".

28. Explore the AX client a bit, open various forms, and navigate through various menus.

29. Close the AX client. (Some machines report a shutdown crash at this point which can be ignored)

30. When control returns to the Sequencing Wizard, click "Launch" again to re-launch the AX client.

31. Explore the AX client a bit, open various forms, and navigate through various menus.

32. Close the AX client. (Some machines report a shutdown crash at this point which can be ignored)

33. Click "Next".

34. Click "Next" on the "Installation Report" screen.

35. On the "Customize" screen select the "Customize" radio button and hit next.

36. On the "Edit Shortcuts" select “Microsoft Dynamics AX 2012” and hit “Edit”. The Sequencer isn’t correctly setting the shortcut icon or version number. Adjust the “Version” field and “OSD File Name” to the appropriate version number then click the “Change Icon…” button.

37. Browse to the path “Q:\AxClient\Client\Bin\AxSearchSetup.exe” and double-click on the Dynamics icon (doesn’t work to pick the one from Ax32.exe).

38. Click “Save” on the “Edit Application” screen

39. Click “Next” on the "Prepare for Streaming" screen and click “Yes” on the ensuring “Launch Applications” dialog

40. On the "Target OS" screen, select 32-bit Windows 7 and 64-bit Windows 7.

41. Click "Next".

42. On the "Create Package" screen hit "Create"

This package should be deployable on a Windows 7 32-bit or Windows 7 64-bit machine.  You should make sure that all the AX 2012 Client’s prerequisites are installed on the clients.

Madelinde Walraven | Senior App-V Support Engineer

Kyle Gleed, Sr. Technical Marketing Manager, VMware

Duncan Epping recently posted some great info on creating custom VIB files (How to create your own .vib files, Some more nuggets about handling vib files).  With custom VIBs making their way into the community this got me thinking that a quick refresher on VIB security would be helpful.  A while back I posted a VIB overview blog in which I discussed how signature files are used to help not only identify if a VIB is officially supported, but also to protect the against any malicious tampering of the VIBs contents.  While custom VIBs definitely have their place (see KB 2007381), do exercise caution when adding them to your ESXi image profiles.  Here's a quick recap of the section on VIB security:

The signature fileis an electronic signature used to verify the level of trust associated with the VIB.  The acceptance level not only helps protect the integrity of the VIB, but it also identifies who created the VIB and the amount of testing and verification that has been done. There are four acceptance levels:

• VMwareCertified:  VIBs created and tested by VMware.  VMware Certified VIBs undergo thorough testing by VMware.

• VMwareAccepted:  VIBs created by a VMware partners that are approved by VMware.  VMware relies on partners to perform the testing, but VMware verifies the results.

• PartnerSupported:  VIBs created and tested by a trusted VMware partner.  The partner performs all testing.  VMware does not verify the results.

• CommunitySupported:  VIBs created by individuals or partners outside of the VMware partner program.  These VIBs do not undergo any VMware or trusted partner testing and are not supported by VMware or its partners. 

All VMware and partner supported VIBs must be signed by a VMware trusted authority, this helps ensure the security of the VIB by preventing any unauthorized tampering of its contents.   Community supported VIBs do not need to be signed, but they are still required to have an empty signature file.  Be careful when using CommunitySupported VIBs as their contents are not tested, monitored or controlled. 

Coinciding with the VIB acceptance levels, ESXi Image Profiles also have an acceptance level.  When the image is created it is assigned one of the four acceptance levels.  Any VIBs added to the image must be at the same acceptance level or higher.  This helps ensure that non-supported VIBs don’t get mixed in with supported VIBs when creating and maintaining ESXi images.

The newest Citrix Receiver for Windows 3.0 (13.0.0.6685) requires almost 150% more memory per user than Citrix ICA Client 11.2. So when optimizing you Citrix servers for the highest user density you should consider if you even need some of these new features if any.

Normally the Citrix client is installed on XenApp servers only to allow for ICA in ICA to internal back-end or Cloud hosted applications.

Register the Citrix Receiver with web browser :

There’s currently also a bug with Citrix Receiver for Windows 3.0 and the Shadow Taskbar. This applies to both XenApp 5 and 6. The workaround for XenApp 6 is to copy the wshadow.exe from the XenApp 6.5 media, but on XenApp 5 there’s currently no hotfix available.

So keep safe and stick to the working Citrix ICA Client 11.2 and save some memory at the same time.

If your users are constantly getting a MSI repair when they visit a Citrix Web Interface site this is most due to the missing ConnectionCenter entry in Registry. Simply push this registry value through Microsoft Group Policy Preferences.

• For x32 this is located in HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• For x64 this is located in HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

While you’re at it, make sure you delete any references in Run to Acrobat Assistant 8.0, Adobe Acrobat Speed Launcher, Adobe ARM, BCSSync and so on. These will only steal unnecessary memory from your system.

Introduction

There are lots of server tasks in Windows Server 2008 that can be done much faster with Windows PowerShell than with a GUI. What you’ll find in this article series are ten common server tasks all done on PowerShell.

In this two part mini-series you’ll learn how to:

1. Change the local administrator password with PowerShell
3. Restart a service with PowerShell
4. Terminate a process with PowerShell
5. Create a disk utilization report with PowerShell
6. Get 10 most recent event log errors with PowerShell
7. Reset access control on a folder with PowerShell
8. Get a server’s uptime with PowerShell
9. Get service pack information with PowerShell
10. Delete old files with PowerShell

In today’s article we’ll start with tasks one through five; in Part 2 in this series we’ll continue with tasks six through ten.

1. Changing the local administrator password with PowerShell

Let’s assume you’re logged in as a domain administrator on a Windows 7 desktop that belongs to your domain. Now, let’s say you want to change the local admin password on a remote server in Chicago named CHI-WIN7-22. After an account password is used for some time, the chances of it getting exposed gets higher. That’s why you need to change your passwords from time to time.

The first thing to do to change the admin password in question is to create an ADSI object for the local administrator on that computer. That can be achieved by typing this in your PowerShell screen:

[ADSI]$Admin=”WinNT://CHI-WIN7-22/Administrator”

This will essentially retrieve the admin account on CHI-WIN7-22 and assign it to an ADSI object named $Admin. The WinNT monicker in that string is case-sensitive and is a common source of error, so take note of that. If you want to connect to another computer, just replace CHI-WIN7-22 with the name of the computer you want to connect to.

Naturally, you’ll want to know first how long the password has been in use to determine whether or not the time has come to change it. You can obtain that information from $Admin by typing in:

$Admin.PasswordAge

That will display the time elapsed since the password of that account was last changed. However, since the resulting value is expressed in seconds, I normally divide it by 86,400, which is the number of seconds in a day:

$Admin.PasswordAge.Value/86400

The result will then be the same time elapsed but expressed in days, which I find more meaningful. If you notice, we used the Value property here. That’s because the PasswordAge is actually stored as a collection, and so we need the value of that collection in order to return a number that we can perform a division operation on.

Finally, you can change the password by invoking the SetPassword method and then using the new password as the argument. For example, if you want the new password to be S3cre+WOrd, then type:

$Admin.SetPassword(“S3cre+WOrd”)

Note: After you hit enter, don’t expect any confirmation message because there won’t be any. Changes will take effect immediately. That’s because what we’re using here is a method, not a cmdlet. Which means, unlike with cmdlets, SetPassword has no support for a -whatif or a -confirm.

That’s all there is to it. Let me now show you the steps we’ve discussed here in theory on an actual PowerShell:

2. Restarting or shutting down a server with PowerShell

Let’s now move on to the task of restarting or shutting down a server using PowerShell. Just like the first task, we’re still going to assume you’re logged in as a domain administrator on a Windows 7 machine that belongs to your domain.

For these tasks, we’ll be using a couple of WMI-based cmdlets, Restart-Computer and Stop-Computer. Although we won’t be showing them here, it’s worth mentioning that these cmdlets accept alternate credentials. Alternate credentials allow you to specify a user account other than the one you are already logged into so that you can perform actions that that (alternate) account has permissions for.

Another thing that’s nice about these cmdlets is that you’ll be able to make use of -whatif and -confirm. That means, if you want to do a restart or a shutdown, you’ll have a way of making  sure you’ll be doing it on the computer you intend to do it on. This can come in handy if you want to perform restarts or shutdowns on a number of computers. You can just pipe a list or group of computers to these cmdlets.

To restart a remote computer or computers, the basic syntax is:

Restart-Computer -ComputerName <string[ ]>,

wherein -ComputerName <string[ ]> is a string array that can be comprised of the name of a single computer or the names of multiple computers. Stop-Computer uses practically the same syntax. So for example, if you want to restart two computers named CHI-DC02 and CHI-FP01, the command would be:

Restart-Computer “CHI-DC02”, “CHI-FP01”

Here’s an actual PowerShell screenshot wherein we used the -whatif argument. You use a -whatif if you simply want to simulate what would happen if you would execute the command in question.

That was pretty straightforward. Let’s now try a more sophisticated example. Let’s assume you have a list of computers in a file named servers.txt. You can use the Get-Content cmdlet to retrieve the contents of that text file, like this:

So, if you have a bunch of computers that you want to restart on a regular basis, you can list down the names of those computers in a text file. Then each time you need to restart them, you simply use the Get-Content cmdlet. Here’s how we used Get-Content and Restart-Computer in a real-world scenario:

First, we got the content from the text file using Get-Content. Then, because we wanted to prepare for the eventuality that some computers would be offline, we piped the list to a where statement for testing. In the where statement, we ran test-connection, which is basically a ping on each computer.

The -quiet returns either true or false, while -count 2 means each computer will only be pinged twice. Those computers that were successfully pinged twice, were then passed along the pipeline.

Next, we used a foreach. Specifically, the objective was that: for each name that came out of the ping test, a green-colored message would be written saying that that computer was “Restarting”. The $_ stands for the current object in the pipeline. Next, the Restart-Computer cmdlet was called to restart each computer that could be pinged. We also used the -force parameter to kick off anyone logged on.

Finally, we used -whatif again to see what would happen without having to actually restart those computers.

3. Restarting a service with PowerShell

Restart-Service is the cmdlet used for restarting a service. Although this cmdlet does not have a built-in mechanism to connect to a remote computer, PowerShell Remoting can be enabled so that you can execute it locally via remoting on the remote computer. This can come in handy when you want to restart a service on a group of computers.

To restart a service locally, simply say: Restart-Service “service”, wherein “service” is the name of the service you want to restart. On the other hand, if you want to restart a service on one or more remote machines, then you can use the Invoke-Command cmdlet and PowerShell Remoting.  

In the PowerShell screenshot below, you see two instances wherein we executed the Restart-Service cmdlet to restart the service called wuauserv, which is the Windows Update service. In the first instance, Restart-Service is executed locally. But in the second instance, it is executed on a remote database server named CHI-DB01 with the help of the Invoke-Command.

By default, Restart-Service doesn’t write any objects in the pipeline unless you use -passthru. So the additional information you see at the bottom (Status, Name, etc.) is a result of using -passthru. If the service runs on multiple computers and you want to restart the service running there as well, just add more computer names in a comma-separated list.

Another way to do that same task is by using WMI. First, you create a WMI object:

gwmi is the alias for Get-WmiObject.

Let me show you first the methods of this object. To do that, we’ll pipe the object to Get-Member (alias is gm).

If you notice, there is no method for restarting ther service. That means, we will have to stop the service using the StopService method and then start it again using the StartService method.

Here’s how you stop the service using the object’s StopService method. The parenthesis indicates it’s a method. If you get a ReturnValue of 0, that means the service stopped successfully. In case you get another value, you can research what that value means by reading the MSDN documentation for the Win32 service class.

To fire the service up again, you use the StartService method.

You can verify by executing the get-service command for that computer. Get-service allows you to connect to a remote computer, so you can simply get that service from the target computer to verify if it is in fact running there.

4. Terminating a Process with Powershell

Another task that’s commonly done on a server is terminating a process. To terminate a process, you use the Stop-Process cmdlet. Again, this can be executed locally or, if you want to stop a process on a remote system, you can use Stop-Process along with PowerShell Remoting.

There are two ways of terminating a process using the Stop-Process cmdlet.

The first one is pretty straightforward. You just run the Stop-Process command and then pass to it either the name of the process or its corresponding ID. In the screenshot below, the name of the process being killed is ‘Calc’ (which is really just the Windows Calculator). Note that Calc is running locally in this example.

The second involves using the Get-Process cmdlet to get one or more processes and then piping them to Stop-Process to kill all those processes at the same time. In the screenshot below, the process being killed is Notepad. Note that kill is an alias of Stop-Process. Again, just like Calc in the previous example, Notepad is running locally.

Let’s now move on to an example where we have a process running remotely. First, let’s fire up a process to kill. So here, we’re starting notepad on a remote computer named chi-fp01.

Next, let’s check whether the process is actually running. For this purpose, we use ps, which is an alias for Get-Process.

Ok. Now that we have a remote process to kill, let’s go ahead and kill it. Like what we did in our discussion on Restarting a Service, we’ll use Invoke-Command and PowerShell Remoting to run the Stop-Process expression on the remote server chi-fp01.

See how the Get-Process alias (ps), which is running in the script block, pipes the process to the Stop-Process alias (kill).

5. Creating a Disk Utilization Report with PowerShell

As admins, we often need to keep track of how much disk space is being used on our servers. We can accomplish this using WMI and the Win32_LogicalDisk class, which will give us information such as the Device ID, the size of the drive, free space, and a few other bits of information.

Using WMI, we can query local or remote computers. We can also perform those queries on either a single or multiple machines. In addition, we can: export the data we query to a CSV file or a database; create a text-based or an HTML-based report; or simply display the output to the screen.

Here’s a sample command using WMI on a local computer.

Get-WmiObject win32_logicaldisk -filter “drivetype=3” | Out-File c:\Reports\Disks.txt

We use the GetWmiObject cmdlet to return information from the Win32_LogicalDisk class. Then we employ the -filter to return only information related to drivetype=3, which stands for fixed logical disks like the c: drive. That means, information regarding USB drives and network drives are not to be included.The returned information is then piped to a text file named Disks.txt.

Here’s a similar example done in an actual PowerShell where we could see an actual output. Note that we are using aliases to shorten the command. Also, in this example, we specified that the output would include the device ID, disk size, the free space, and the system name.

While there’s certainly nothing wrong with that output, it sure could use a couple of improvements. For example, you might want to display the size and free space in Gigabytes instead of bytes. We can actually get a more elegant output by adding a few extra steps. Let me show you how.

For this purpose, we’re going to create a function named Get-DiskUtil. Although the succeeding example is going to show you how to do things interactively in the shell, you can actually put this function in a script file, load it into your profile, or load it to your other scripts so that you can use it again later on.

Here’s the function I’m talking about:

Let’s dissect that function now.

The function is going to take a computer name as its parameter and it will default to the local computer name.

Now we use the Process script blocks that this computer name property can be piped-in to the function. If it gets a piped-in value ($_), then it’s going to set the computer name variable to that piped-in value. Otherwise, it will take the computer name that gets piped-in as a parameter.

Next up is the GetWmiObject expression.

The output of that expression is piped to the Select-Object cmdlet (represented by its alias, Select). We then make use of a hashtable to create a custom property called Computername. This basically renames the SystemName of the current object ($_) to Computername. The DeviceID is passed along as is.

We then deploy a couple more hashtables. The first one takes the Size property, divides it by 1GB, expresses the result into two decimal points, and renames the property to SizeGB. The second one takes the Freespace property and does practically the same thing to it.

Next, we create a new property called UsedGB, which doesn’t exist in WMI. It simply takes the difference between the Size and FreeSpace properties and divides the result by 1GB.

Finally, we also create another property called PerFree, which stands for “percent free”. This shows the free space as a fraction of total disk size expressed in percentage. And that completes the function.

Here’s the function in action wherein we passed to it the name of the computer, piped the output to Format-Table (or ft), and set the final output to auto-size using -auto.

While all this looks nice and pretty, there’s still a lot more that we can get from this function. So let’s say that on a weekly basis, you need to get a disk utilization report of all the servers in your environment. Here are a couple of different ways you can work with this data.

The first thing we’re going to do is to save the results of our expression to the variable $data. That’s so we don’t have to type in the command repeatedly. Next, we pipe the results to the where object, do the ping tests (pinging it twice when it can be pinged), and then pipe the computer name to our newly-created Get-DiskUtil function.

You’ll know that the command is done executing when you get the prompt back.

That would mean the data has already been stored in $data. You can then pipe the information in $data to sort by computername and then set it to auto-resize. You can also send that information to Out-Printer or Out-File.

Similarly, if you want to load that information to a SQL database or an Excel spreadsheet, you can convert the data to a CSV file like this:

Later on, if you import that CSV file, you will be able to obtain a snapshot of the disk utilization status of those disks right at the time the command is run.

Here’s a portion of that snapshot:

As a final example, let me show you how to create an HTML report that perhaps you will want to put on your Internet server to show disk utilization. So that, as an IT admin, you can go ahead and take a quick peek at your disk utilization status even while you’re outside the office.

So again, you start by taking $data and pipe it to Sort Computername. You then pipe the result to the ConvertTo-HTML cmdlet. You also give it a title and specify a CSS path. The CSS part is needed because ConverToHTML does not do any formatting. So if you want your report to look pretty you’ll need that CSS file. Finally, you need to send the output to a file.

Now that your file’s ready, you can then look at the file by using the start command.

Here’s a sample of that HTML report.

Remember that the values on this report are up-to-date.

Conclusion

That wraps up Part 1 of this article. In the second part, we’ll take on 5 more server tasks that can be done using PowerShell.