Posey's Tips & Tricks
Using PowerShell To Get Detailed Role Information
PowerShell makes it possible to gain a detailed understanding of what roles do, and of the relationship between roles and features.
In the previous column, I showed you how to get information about which roles and features are installed on a Windows Server.
As helpful as the techniques in that column may be, however, there is a whole lot more that you can do when it comes to viewing roles and features. In fact, PowerShell makes it possible to gain a detailed understanding of what roles do, and of the relationship between roles and features.
For the sake of demonstration, let's pretend that I have absolutely no knowledge of the Hyper-V role. Let's also pretend that I just happened to notice the Hyper-V role installed on a server and want to figure out what it is, what it does and how it relates to other components, using nothing but the Get-WindowsFeature cmdlet.
Normally, when you run the Get-WindowsFeature cmdlet, it will show you the role or feature's name and whether it is installed, but there is a lot more information available. Since I have never heard of Hyper-V before, maybe a good place to start is by retrieving a description of the role. I can do that with this command:
Get-WindowsFeature Hyper-V | Select-Object Description
[Click on image for larger view.] Figure 1: Here is a description of the Hyper-V role.
OK, that's a nice start, but since I still don't know much about this feature, maybe it would be good to find out about its dependencies. I can list the feature's dependencies by using a variation of the previous command:
Get-WindowsFeature Hyper-V | Select-Object DependsOn
In this case, there aren't any dependencies. But maybe there are some sub-components that depend on the Hyper-V feature. We can find out what those components are and even see their descriptions by using the following command:
Get-WindowsFeature | Where-Object {$_.DependsOn -eq 'Hyper-V'} | Select-Object DisplayName, Description
The command above looks for any feature that depends on the Hyper-V service and then outputs the display name and the description for that feature. If you look at Figure 2, you can see that there are two features that depend on the Hyper-V role.
[Click on image for larger view.] Figure 2: There are two features that depend on the Hyper-V role.
Another helpful thing to know is whether this mystery feature named Hyper-V is actually doing anything. We know it is installed, but is it tied to a system service? And if so, is that service actually running? Here is how we can find out:
$S = Get-WindowsFeature Hyper-V | Select-Object -ExpandProperty SystemService
Get-Service $S | Select-Object Name, DisplayName, Status
When we perform the initial selection of the SystemService object, we have to specify the ExpandProperty parameter. The reason for this is that there can be multiple system services tied to a role, and all of those services get wrapped up into a single property called SystemService. In the case of Hyper-V, however, there is only one system service, and it is called VMMS.
Another thing that we are doing in the code above is creating a variable called $S and mapping the Get-WindowsFeature command (and all of the required parameters) to that variable. The end result is that the variable will end up storing the name of the system service that is tied to the Hyper-V role.
To output the particulars of the VMMS service, we are using the Get-Service cmdlet in conjunction with the $S variable, which contains the service name. I know that I said that we were only going to be using the Get-WindowsFeature cmdlet, but I just had to throw in one more command. You can see the output from these commands in Figure 3.
[Click on image for larger view.] Figure 3: The Hyper-V service is running.
From here, I could begin tracing service dependencies, but that is another discussion for another day. Instead, I want to wrap things up by mentioning that some Windows Server roles require additional configuration after being installed. For example, simply installing the Active Directory Domain Services alone isn't enough to get a server to act as a domain controller. There is a configuration process that you have to work through.
Now, Hyper-V does not require any additional configuration after installation, but let's pretend that we don't know that and want to find out if any extra configuration is needed. We can find out by running this command:
Get-WindowsFeature Hyper-V | Select-Object PostConfigurationNeeded
An output value of True would indicate that additional configuration is needed, while a value of False indicates that no more configuration is required.
There is actually a lot more that can be done with Get-WindowsFeature. If we wanted to, we could trace the entire feature hierarchy chain, track down the event log entries associated with the role, or even see which Best Practices Analyzer is associated with the role.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.