Although not a widely publicized feature, Windows Server has long included a built-in software inventory logging feature. To use this feature, you will need to be running Windows Server 2008 R2 or higher (it doesn’t work on Windows 10). If you happen to be using Windows Server 2012 R2, you will need to make sure that KB3000850 and KB3060681 are installed before you use the inventory feature.
The method that you will want to use really depends on your goals. If you just want to find out which programs have been installed, there is a quick and dirty way to find out. Here is a PowerShell command you can use:
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-Table –AutoSize
The command listed above essentially mimics the list of applications that are displayed in the Windows Control Panel. It’s actually intended primarily for use with Windows 10 rather than Windows Server.
Unlike Windows 10, Windows Server has native software inventory logging functions built into the operating system. These capabilities are all exposed through Windows PowerShell.
To see what the native software inventory logging looks like, log onto a Windows Server and try entering the Get-SilData cmdlet into PowerShell. If you look at the screenshot below, you can see that the command indicates that the Windows Admin Center and Hyper-V are installed on this particular server. Beneath the software inventory information, PowerShell displays some basic information about the server, such as its make and model, CPU count, and Windows version. Somewhat surprisingly, however, there are no memory statistics provided.
There are other software inventory-related cmdlets that you can use to view additional information. For example, the Get-SilWindowsUpdate cmdlet shows the Windows updates that have been installed. You can see this cmdlet and a couple of other cmdlets such as Get-SilComputer and Get-SilSoftware being demonstrated in the next screenshot.
As handy as this functionality may be, it is worth noting that there is a big difference between manually retrieving a server’s software inventory via the Get-SilData cmdlet and performing actual software inventory logging. Logging implies that you are collecting inventory data over time rather than simply doing a quick check to see what is installed at a given moment. The main advantage of logging is that it lets you see how a server’s software inventory has changed over time. More importantly, logging creates a record of when each item or feature was installed.
The only real downside to using Windows Server’s native software inventory logging feature is that it can be at least a little bit tricky to set up. The reason for this is that although the logs are created locally, it is best to ship those logs to a centralized aggregation server. This prevents the logs from being tampered with, of lost if the server’s hard disk crashes.
Using log shipping means that you will have to create a central repository that stores the logs for all of your Windows Servers. You will also have to configure each server’s software inventory logging feature to use the repository that you have created, rather than storing all of the logs locally. Incidentally, the vast majority of the Microsoft documentation pertaining to the Windows Server Software Inventory Logging feature is geared toward setting up centralized logging through the use of an aggregation server, but storing logging data locally on each server is also an option. However, centralized logging is more easily scalable and tends to be more secure.
If you plan to build a centralized collection of software inventory logs, then you will need to set up a Windows Server to act as a logging aggregator.
There are a few other components that you will need in addition to the aggregator. Specifically, you will need a Windows Server machine that can act as the aggregator server. That server will need to run the IIS role with the .NET Framework (version 4.5), the WCF services, and HTTP activation. You will also need SQL Server and you will need a 64-bit edition of Microsoft Excel if you plan to use the reporting feature.
It is also important to note that the aggregation process depends heavily on the use of SSL certificates. You will need an SSL certificate for the aggregation server and for each server that you plan to inventory. In each case, the certificate will need to match the server’s name.
Because the certificates are used for authentication, you will need to provide the aggregator with the certificate thumbprints of the servers that will be providing software inventory information. To do so, you will have to use the Start-SilAggregator cmdlet to start the aggregator and then use the Set-SilAggregator cmdlet with the -AddCertificateThumbprint switch to add each client’s certificate thumbprint to the aggregator.
There is also a bit of configuration that will need to be done on the client-side. You will need to use the Set-SilLogging cmdlet with the TargetURI switch, followed by the URL associated with your aggregation server. It is worth noting that this URL must be in HTTPS format, and you will have to make sure that your firewalls are configured to allow HTTPS traffic to pass.
Once you have provided the URL, you will need to use the Set-SilLogging cmdlet one more time. This time, you will have to use the -CertificateThumbprint switch, in conjunction with the thumbprint that you want to use for authentication.
Finally, you will need an account that the aggregator can use to poll the servers that are being inventoried. This account should not be privileged.
There is a considerable amount of work involved in setting up software inventory logging. That being the case, it is a good idea to review the Microsoft documentation before delving into the setup process. You can find the documentation for the Software Inventory Logging Aggregator here. You can find the client-side documentation (the documentation for the servers that are being inventoried) here.
Setting PowerShell execution policies at the Group Policy level can greatly enhance your organization’s security.…
Ah, the good old days — when Exchange 2010 was king. But with each new…
The GDPR and the CCPA are both aimed at protecting privacy. Although many similarities exist…
Azure DevOps is fast becoming the next big thing. This Azure DevOps Quick Tip shows…
That old messaging platform has served you well, but maybe it’s time to move on.…