Skip navigation

PoShSWI.png

In my previous posts, I talked about building the virtual machine and then about prepping the disks.  That's all done for this particular step.

 

This is a long set of scripts.  Here's the list of what we'll be doing:

  1. Variable Declaration
  2. Installing Windows Features
  3. Enabling Disk Performance Metrics
  4. Installing some Utilities
  5. Copying the IIS Folders to a new Location
  6. Enable Deduplication (optional)
  7. Removing unnecessary IIS Websites and Application Pools
  8. Tweaking the IIS Settings
  9. Tweaking the ASP.NET Settings
  10. Creating a location for the TFTP and SFTP Roots (for NCM)
  11. Configuring Folder Redirection
  12. Pre-installing ODBC Drivers (for SAM Templates)

 

Stage 1: Variable Declaration

This is super simple (as variable declarations should be)

#region Variable Declaration
$PageFileDrive = "D:\"
$ProgramsDrive = "E:\"
$WebDrive      = "F:\"
$LogDrive      = "G:\"
#endregion

 

Stage 2: Installing Windows Features

This is the longest part of the process.. and it can't be helped.  The Orion installer will do this for you automatically, but if I do it in advance, I can play with some of the settings before I actual perform the installation.

#region Add Necessary Windows Features
# this is a list of the Windows Features that we'll need
# it's being filtered for those which are not already installed
$Features = Get-WindowsFeature -Name FileAndStorage-Services, File-Services, FS-FileServer, Storage-Services, Web-Server, Web-WebServer, Web-Common-Http, Web-Default-Doc, Web-Dir-Browsing, Web-Http-Errors, Web-Static-Content, Web-Health, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Performance, Web-Stat-Compression, Web-Dyn-Compression, Web-Security, Web-Filtering, Web-Windows-Auth, Web-App-Dev, Web-Net-Ext, Web-Net-Ext45, Web-Asp-Net, Web-Asp-Net45, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Mgmt-Tools, Web-Mgmt-Console, Web-Mgmt-Compat, Web-Metabase, NET-Framework-Features, NET-Framework-Core, NET-Framework-45-Features, NET-Framework-45-Core, NET-Framework-45-ASPNET, NET-WCF-Services45, NET-WCF-HTTP-Activation45, NET-WCF-MSMQ-Activation45, NET-WCF-Pipe-Activation45, NET-WCF-TCP-Activation45, NET-WCF-TCP-PortSharing45, MSMQ, MSMQ-Services, MSMQ-Server, FS-SMB1, User-Interfaces-Infra, Server-Gui-Mgmt-Infra, Server-Gui-Shell, PowerShellRoot, PowerShell, PowerShell-V2, PowerShell-ISE, WAS, WAS-Process-Model, WAS-Config-APIs, WoW64-Support, FS-Data-Deduplication | Where-Object { -not $_.Installed }
$Features | Add-WindowsFeature
#endregion

 

Without the comments, this is 2 lines.  Yes, only 2 lines, but very important ones.  The very last Windows Feature that I install is Data Deduplication (FS-Data-Deduplication).  If you don't want this, you are free to remove this from the list and skip Stage 6.

 

Stage 3: Enabling Disk Performance Metrics

This is something that is disabled in Windows Server by default, but I like to see them, so I re-enable them.  It's super-simple.

#region Enable Disk Performance Counters in Task Manager
Start-Process -FilePath "C:\Windows\System32\diskperf.exe" -ArgumentList "-Y" -Wait
#endregion

 

Stage 4: Installing some Utilities

This is entirely for me.  There are a few utilities that I like on every server that I use regardless of version.  You can configure this to do it in whatever way you like.  Note that I no longer install 7-zip as part of this script because I'm deploying it via Group Policy.

#region Install 7Zip
# This can now be skipped because I'm deploying this via Group Policy
# Start-Process -FilePath "C:\Windows\System32\msiexec.exe" -ArgumentList "/i", "\\Path\To\Installer\7z1604-x64.msi", "/passive" -Wait
#endregion
#region Install Notepad++
# Install NotePad++ (current version)
# Still need to install the Plugins manually at this point, but this is a start
Start-Process -FilePath "\\Path\To\Installer\npp.latest.Installer.exe" -ArgumentList "/S" -Wait
#endregion
#region Setup UTILS Folder
# This contains the SysInternals and Unix Utils that I love so much.
$RemotePath = "\\Path\To\UTILS\"
$LocalPath  = "C:\UTILS\"
Start-Process -FilePath "C:\Windows\System32\robocopy.exe" -ArgumentList $RemotePath, $LocalPath, "/E", "/R:3", "/W:5", "/MT:16" -Wait
$MachinePathVariable = [Environment]::GetEnvironmentVariable("Path", "Machine")
if ( -not ( $MachinePathVariable -like '*$( $LocalPath )*' ) )
{
    $MachinePathVariable += ";$LocalPath;"
    $MachinePathVariable = $MachinePathVariable.Replace(";;", ";")
    Write-Host "Adding C:\UTILS to the Machine Path Variable" -ForegroundColor Yellow
    Write-Host "You must close and reopen any command prompt windows to have access to the new path"
    [Environment]::SetEnvironmentVariable("Path", $MachinePathVariable, "Machine")
}
else
{
    Write-Host "[$( $LocalPath )] already contained in machine environment variable 'Path'"
}
#endregion

 

Stage 5: Copying the IIS folders to a New Location

I don't want my web files on the C:\ Drive.  It's just something that I've gotten in the habit of doing from years of IT, so I move them using robocopy.  Then I need to re-apply some permissions that are stripped.

#region Copy the IIS Root to the Web Drive
# I can do this with Copy-Item, but I find that robocopy works better at keeping permissions
Start-Process -FilePath "robocopy.exe" -ArgumentList "C:\inetpub", ( Join-Path -Path $WebDrive -ChildPath "inetpub" ), "/E", "/R:3", "/W:5" -Wait
#endregion
#region Fix IIS temp permissions
$FolderPath = Join-Path -Path $WebDrive -ChildPath "inetpub\temp"
$CurrentACL = Get-Acl -Path $FolderPath
$AccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList "NT AUTHORITY\NETWORK SERVICE", "FullControl", ( "ContainerInherit", "ObjectInherit" ), "None", "Allow"
$CurrentACL.SetAccessRule($AccessRule)
$CurrentACL | Set-Acl -Path $FolderPath
#endregion

 

Stage 6: Enable Deduplication (Optional)

I only want to deduplicate the log drive - I do this via this script.

#region Enable Deduplication on the Log Drive
Enable-DedupVolume -Volume ( $LogDrive.Replace("\", "") )
Set-DedupVolume -Volume ( $LogDrive.Replace("\", "") ) -MinimumFileAgeDays 0 -OptimizeInUseFiles -OptimizePartialFiles
#endregion

 

Stage 7: Remove Unnecessary IIS Websites and Application Pools

Orion will create its own website and application pool, so I don't need the default ones.  I destroy them with PowerShell.

#region Delete Unnecessary Web Stuff
Get-WebSite -Name "Default Web Site" | Remove-WebSite -Confirm:$false
Remove-WebAppPool -Name ".NET v2.0" -Confirm:$false
Remove-WebAppPool -Name ".NET v2.0 Classic" -Confirm:$false
Remove-WebAppPool -Name ".NET v4.5" -Confirm:$false
Remove-WebAppPool -Name ".NET v4.5 Classic" -Confirm:$false
Remove-WebAppPool -Name "Classic .NET AppPool" -Confirm:$false
Remove-WebAppPool -Name "DefaultAppPool" -Confirm:$false
#endregion

 

Step 8: Tweak the IIS Settings

This step is dangerous.  There's no other way to say this.  If you get the syntax wrong you can really screw up your system... this is also why I save a backup of the file before I make and changes.

#region Change IIS Application Host Settings
# XML Object that will be used for processing
$ConfigFile = New-Object -TypeName System.Xml.XmlDocument
# Change the Application Host settings
$ConfigFilePath = "C:\Windows\System32\inetsrv\config\applicationHost.config"
# Load the Configuration File
$ConfigFile.Load($ConfigFilePath)
# Save a backup if one doesn't already exist
if ( -not ( Test-Path -Path "$ConfigFilePath.orig" -ErrorAction SilentlyContinue ) )
{
    Write-Host "Making Backup of $ConfigFilePath with '.orig' extension added" -ForegroundColor Yellow
    $ConfigFile.Save("$ConfigFilePath.orig")
}
# change the settings (create if missing, update if existing)
$ConfigFile.configuration.'system.applicationHost'.log.centralBinaryLogFile.SetAttribute("directory", [string]( Join-Path -Path $LogDrive -ChildPath "inetpub\logs\LogFiles" ) )
$ConfigFile.configuration.'system.applicationHost'.log.centralW3CLogFile.SetAttribute("directory", [string]( Join-Path -Path $LogDrive -ChildPath "inetpub\logs\LogFiles" ) )
$ConfigFile.configuration.'system.applicationHost'.sites.siteDefaults.logfile.SetAttribute("directory", [string]( Join-Path -Path $LogDrive -ChildPath "inetpub\logs\LogFiles" ) )
$ConfigFile.configuration.'system.applicationHost'.sites.siteDefaults.logfile.SetAttribute("logFormat", "W3C" )
$ConfigFile.configuration.'system.applicationHost'.sites.siteDefaults.logfile.SetAttribute("logExtFileFlags", "Date, Time, ClientIP, UserName, SiteName, ComputerName, ServerIP, Method, UriStem, UriQuery, HttpStatus, Win32Status, BytesSent, BytesRecv, TimeTaken, ServerPort, UserAgent, Cookie, Referer, ProtocolVersion, Host, HttpSubStatus" )
$ConfigFile.configuration.'system.applicationHost'.sites.siteDefaults.logfile.SetAttribute("period", "Hourly")
$ConfigFile.configuration.'system.applicationHost'.sites.siteDefaults.traceFailedRequestsLogging.SetAttribute("directory", [string]( Join-Path -Path $LogDrive -ChildPath "inetpub\logs\FailedReqLogFiles" ) )
$ConfigFile.configuration.'system.webServer'.httpCompression.SetAttribute("directory", [string]( Join-Path -Path $WebDrive -ChildPath "inetpub\temp\IIS Temporary Compressed File" ) )
$ConfigFile.configuration.'system.webServer'.httpCompression.SetAttribute("maxDiskSpaceUsage", "2048" )
$ConfigFile.configuration.'system.webServer'.httpCompression.SetAttribute("minFileSizeForComp", "5120" )
# Save the file
$ConfigFile.Save($ConfigFilePath)
Remove-Variable -Name ConfigFile -ErrorAction SilentlyContinue
#endregion

 

There's a lot going on here, so let me see if I can't explain it a little.

I'm accessing the IIS Application Host configuration file and making changes.  This file governs the entire IIS install, which is why I make a backup.

The changes are:

  • Change any log file location (lines 15 - 17, 21)
  • Define the log type (line 18)
  • Set the elements that I want in the logs (line 19)
  • Set the log roll-over period to hourly (line 20)
  • Set the location for temporary compressed files (line 22)
  • Set my compression settings (lines 23-24)

 

Stage 9: Tweaking the ASP.NET Configuration Settings

We're working with XML again, but this time it's for the ASP.NET configuration.  I use the same process as Stage 8, but the changes are different.  I take a backup again.

#region Change the ASP.NET Compilation Settings
# XML Object that will be used for processing
$ConfigFile = New-Object -TypeName System.Xml.XmlDocument
# Change the Compilation settings in the ASP.NET Web Config
$ConfigFilePath = "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config"
Write-Host "Editing [$ConfigFilePath]" -ForegroundColor Yellow
# Load the Configuration File
$ConfigFile.Load($ConfigFilePath)
# Save a backup if one doesn't already exist
if ( -not ( Test-Path -Path "$ConfigFilePath.orig" -ErrorAction SilentlyContinue ) )
{
    Write-Host "Making Backup of $ConfigFilePath with '.orig' extension added" -ForegroundColor Yellow
    $ConfigFile.Save("$ConfigFilePath.orig")
}
# change the settings (create if missing, update if existing)
$ConfigFile.configuration.'system.web'.compilation.SetAttribute("tempDirectory", [string]( Join-Path -Path $WebDrive -ChildPath "inetpub\temp") )
$ConfigFile.configuration.'system.web'.compilation.SetAttribute("maxConcurrentCompilations", "16")
$ConfigFile.configuration.'system.web'.compilation.SetAttribute("optimizeCompilations", "true")
# Save the file
Write-Host "Saving [$ConfigFilePath]" -ForegroundColor Yellow
$ConfigFile.Save($ConfigFilePath)
Remove-Variable -Name ConfigFile -ErrorAction SilentlyContinue
#endregion

 

Again, there's a bunch going on here, but the big takeaway is that I'm changing the temporary location of the ASP.NET compilations to the drive where the rest of my web stuff lives and the number of simultaneous compilations. (lines 16-18)

 

Stage 10: Create NCM Roots

I hate having uploaded configuration files (from network devices) saved to the root drive.  This short script creates folders for them.

#region Create SFTP and TFTP Roots on the Web Drive
# Check for & Configure SFTP and TFTP Roots
$Roots = "SFTP_Root", "TFTP_Root"
ForEach ( $Root in $Roots )
{
    if ( -not ( Test-Path -Path ( Join-Path -Path $WebDrive -ChildPath $Root ) ) )
    {
        New-Item -Path ( Join-Path -Path $WebDrive -ChildPath $Root ) -ItemType Directory
    }
}
#endregion

 

Stage 11: Configure Folder Redirection

This is the weirdest thing that I do.  Let me see if I can explain.

 

My ultimate goal is to automate installation of the software itself.  The default directory for installation the software is C:\Program Files (x86)\SolarWinds\Orion (and a few others).  Since I don't really like installing any program (SolarWinds stuff included) on the O/S drive, this leaves me in a quandary.  I thought to myself, "Self, if this was running on *NIX, you could just do a symbolic link and be good."  Then I reminded myself, "Self, Windows has symbolic links available."  Then I just needed to tinker until I got things right.  After much annoyance, and rolling back to snapshots, this is what I got.

#region Folder Redirection
$Redirections = @()
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]1; SourcePath = "C:\ProgramData\SolarWinds"; TargetDrive = $ProgramsDrive } )
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]2; SourcePath = "C:\ProgramData\SolarWindsAgentInstall"; TargetDrive = $ProgramsDrive } )
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]3; SourcePath = "C:\Program Files (x86)\SolarWinds"; TargetDrive = $ProgramsDrive } )
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]4; SourcePath = "C:\Program Files (x86)\Common Files\SolarWinds"; TargetDrive = $ProgramsDrive } )
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]5; SourcePath = "C:\ProgramData\SolarWinds\Logs"; TargetDrive = $LogDrive } )
$Redirections += New-Object -TypeName PSObject -Property ( [ordered]@{ Order = [int]6; SourcePath = "C:\inetput\SolarWinds"; TargetDrive = $WebDrive } )
$Redirections | Add-Member -MemberType ScriptProperty -Name TargetPath -Value { $this.SourcePath.Replace("C:\", $this.TargetDrive ) } -Force
ForEach ( $Redirection in $Redirections | Sort-Object -Property Order )
{
    # Check to see if the target path exists - if not, create the target path
    if ( -not ( Test-Path -Path $Redirection.TargetPath -ErrorAction SilentlyContinue ) )
    {
        Write-Host "Creating Path for Redirection [$( $Redirection.TargetPath )]" -ForegroundColor Yellow
        New-Item -ItemType Directory -Path $Redirection.TargetPath | Out-Null
    }
    # Build the string to send to the command prompt
    $CommandString = "mklink /D /J `"$( $Redirection.SourcePath )`" `"$( $Redirection.TargetPath )`""
    Write-Host "Executing [$CommandString]... " -ForegroundColor Yellow -NoNewline
    # Execute it
    Start-Process -FilePath "cmd.exe" -ArgumentList "/C", $CommandString -Wait
    Write-Host "[COMPLETED]" -ForegroundColor Green
}
#endregion

The reason for the "Order" member in the Redirections object is because certain folders have to be built before others... IE: I can't build X:\ProgramData\SolarWinds\Logs before I build X:\ProgramData\SolarWinds.

 

When complete the folders look like this:

mklinks.png

Nice, right?

 

Stage 12: Pre-installing ODBC Drivers

I monitor many database server types with SolarWinds Server & Application Monitor.  They each require drivers  - I install them in advance (because I can).

#region Pre-Orion Install ODBC Drivers
#
# This is for any ODBC Drivers that I want to install to use with SAM
# You don't need to include any driver for Microsoft SQL Server - it will be done by the installer
# I have the drivers for MySQL and PostgreSQL in this share
#
# There is also a Post- share which includes the files that I want to install AFTER I install Orion.
$Drivers = Get-ChildItem -Path "\\Path\To\ODBC\Drivers\Pre\" -File
ForEach ( $Driver in $Drivers )
{
    if ( $Driver.Extension -eq ".exe" )
    {
        Write-Host "Executing $( $Driver.FullName )... " -ForegroundColor Yellow -NoNewline
        Start-Process -FilePath $Driver.FullName -Wait
        Write-Host "[COMPLETED]" -ForegroundColor Green
    }
    elseif ( $Driver.Extension -eq ".msi" )
    {
        # Install it using msiexec.exe
        Write-Host "Installing $( $Driver.FullName )... " -ForegroundColor Yellow -NoNewline
        Start-Process -FilePath "C:\Windows\System32\msiexec.exe" -ArgumentList "/i", "`"$( $Driver.FullName )`"", "/passive" -Wait
        Write-Host "[COMPLETED]" -ForegroundColor Green
    }
    else
    {
        Write-Host "Bork-Bork-Bork on $( $Driver.FullName )"
    }
}
#endregion

 

Running all of these with administrator privileges cuts this process down to 2 minutes and 13 seconds.  And over 77% of that is installing the Windows Features.

 

Execution time: 2:13

Time saved: over 45 minutes

 

This was originally published on my personal blog as Building my Orion Server [Scripting Edition] – Step 3 – Kevin's Ramblings

Since we launched the PerfStack™ feature in the beginning of 2017, we have seen a lot of interesting use cases from our customers. If you are unfamiliar with PerfStack, you can check out Drag & Drop Answers to Your Toughest IT Questions, where aLTeReGo outlines the basic functions of the feature. Those that are familiar have come to realize just how powerful the feature is for troubleshooting issues within their environment. Whether you're a system, network, virtualization, storage, or other IT administrator, being able to see metric data across the entire infrastructure stack is very valuable.

 

One of the common use cases I hear about lately, is visualizing synthetic web transaction metrics in the context of application performance metrics. For instance, lets say you have an intranet site and you need to monitor it for performance issues, including end users access and performance from multiple locations. With WPM and SAM, this is a reality. However, before PerfStack, you needed to browse multiple pages to compare metric data against each other.

 

In PerfStack, you can easily add all of the response times for WPM transactions, from multiple locations, to a single metric palette, and quickly visualize those metrics together. In the scenario of the intranet site mentioned above, you can see the response time average duration, from each of the four locations that are monitoring this particular transaction.

You can also easily add all of the transaction steps, for a particular transaction, to provide a more granular view of the response time of your web applications. All you have to do is click on the related entities icon for a given transaction. Then, add the related transaction step entities and subsequent response time metrics. This will allow you to quickly see which steps are contributing to the elevated response time for the related transaction.

save image

But what about the performance metrics of the application itself, and the infrastructure that hosts it? Those metrics are crucial to determining root cause of application issues. With Perfstack, it is easy to quickly add those metrics to the metric palette when using the related entities function. This does require a pre-requisite to be configured. When configuring your WPM transaction you will need to define related applications and nodes as shown below.

Once that is done, Orion does the rest. As you can see in AppStack, the relationship from the transaction to the application and the rest of the infrastructure stack is fully visible.

save image

This will allow you to add and remove all of the necessary entities and metrics to a PerfStack project, to complete your troubleshooting efforts. The more Orion Platform products you have, the more entities you will be able to collect metrics from and be able to visualize in PerfStack. Below you can see the multitude of data available through the relationships in Orion. When all of the needed metrics are added, you can save the PerfStack project to recall for future troubleshooting efforts.

save image

We have tried to make it easy to access the data needed to quickly troubleshoot any issues that arise in your environment. With the data at your finger tips you can drastically reduce the mean time to resolution for many issues. We all know that shorter mean time to resolution is important, because performance problems equate to unhappy end user. And when end users aren't happy...

iStock-135165692.jpg

Hopefully you are already reaping the benefit from the many improvements that were made in Network Performance Monitor 12.1, Server & Application Monitor 6.4, Storage Resource Monitor 6.4, Virtualization Manager 7.1, Netflow Traffic Analyzer 4.2.2, and Network Configuration Manager 7.6. If you haven't yet had a chance to upgrade to these releases, I encourage you to do so at your earliest convenience, as there are a ton of exciting new features that you're missing out on.

 

Something a few who already upgraded may have seen, is one or more deprecation notices within the installer. These may have included reference to older Windows operating systems or Microsoft SQL versions. Note that these deprecation notices will only appear when upgrading to any of the product versions listed above, provided you are installing on any of the Windows OS or SQL versions deprecated in those releases. But what does it mean when a feature or software dependency has been deprecated? Does this mean it's no longer supported, or those versions can't be used anymore?

 

Upgrade.png

 

Many customers throughout the years have requested advance notice whenever older operating systems and SQL database versions would no longer be supported in future versions of Orion, allowing them sufficient time to properly plan for those upgrades. Deprecation does not mean that those versions can't be used, or that they are no longer supported at the time the deprecation notice is posted. Rather, those deprecated versions continue to remain fully supported, but that future Orion product releases will likely no longer support them. As such, all customers affected by these deprecation notices should take this opportunity to begin planning their migrations if they wish to stay current with the latest releases. So what exactly was deprecated with the Q1'17 Orion product releases?

 

Windows Server 2008 R2

 

Released on October 22, 2009, Microsoft ended mainstream support for Windows Server 2008 R2 SP1 six years later on January 13, 2015. For customers, this means that while new security updates continue to be made available for the aging operating system, bug fixes for critical issues will require a separate purchase of an Extended Hotfix Support contract agreement; in addition to paying for each fix requested. Since so few of our customers have such agreements with Microsoft, the only recourse, often times, is an unplanned, out-of-cycle, operating system upgrade.

 

Microsoft routinely launches new operating system versions, with major releases on average every four years, and minor version releases approximately every two. As new server operating system versions are released, customer adoption begins immediately thereafter; sometimes even earlier, during Community Technical Preview, where some organizations place production workloads on the pre-released operating system. Unfortunately, in order to leverage the technological advances these later versions of Windows provide, it occasionally requires losing backwards compatibility support for some older versions along the way. Similar challenges occur also during QA testing whenever a new operating system is released. At some point it's simply not practical to thoroughly and exhaustively test every possible permutation of OS version, language, hotfix rollup or service pack. Eventually the compatibility matrix becomes so unwieldy that a choice between quality or compatibility must be made; and really that's not a choice at all.

 

 

SQL Server 2008 / 2008 R2

 

SQL Server 2008 was released on August 6, 2008, with SQL 2008 R2 being released just four months shy of two years later, on April 21, 2010. Seven years later, there have been tremendous advances in Microsoft's SQL server; from the introduction of new redundancy options, to technologies like OLTP and columnstore indexes, which provide tremendous performance improvements. Maintaining compatibility with older versions of Microsoft SQL precludes Orion from being able to leverage these and other advances made in later releases of Microsoft SQL Server, many of which have potential to tremendously accelerate the overall performance and scalability of future releases of the Orion platform.

 

If you happen to be running SQL Server 2008 or SQL 2008 R2 on Windows Server 2008 or 2008 R2, not to worry. There's no need to forklift your existing SQL server prior to upgrading to the next Orion release. In fact, you don't even need to upgrade the operating system of your SQL server, either. Microsoft has made the in-place upgrade process from SQL 2008/R2 to SQL 2014 extremely simple and straightforward. If your SQL server is running on Windows Server 2012 or later, then we recommend upgrading directly to SQL 2016 SP1 or beyond so you can limit the potential for additional future upgrades when/if support SQL 2012 is eventually deprecated.

 

Older Orion Version Support for Windows & SQL

 

Once new Orion product module versions are eventually released which no longer support running on Windows Server 2008, 2008 R2, or SQL 2008/R2, SolarWinds will continue to provide official support for those previous supported Orion module versions running on these older operating systems and SQL server versions. These changes only affect Orion module releases running Orion Core versions later than 2017.1. If you are already running the latest version of an Orion product module on Windows Server 2008/R2 or SQL 2008/R2 and have no ability to upgrade either of those in the near future, not to worry. Those product module versions will continue to be supported on those operating system and SQL versions for quite some time to come.

 

Monitoring vs Running

 

While the next release of Orion will no longer support running on Windows or SQL 2008/R2, support for monitoring systems which are running on these older versions of Windows and SQL will absolutely remain supported. This also includes systems where the Orion Agent is deployed. What that means is if you're using the Orion agent to monitor systems running on Windows Server 2008 or Windows Server 2008 R2, rest assured that support for monitoring those older systems with the Orion Agent remains fully intact in the next Orion release. The same is also true if you're monitoring Windows or SQL 2008/R2 agentlessly via WMI, SNMP, etc. You're next upgrade will not impact your ability to monitor these older operating systems or SQL versions in any way.

 

 

32Bit vs 64Bit

 

Support for installing evaluations on 32bit operating systems will also be dropped from all future releases of Orion product modules, allowing us to begin the migration of Orion codebase to 64bit. In doing this, it should improve the stability, scalability, and performance for larger Orion deployments. Once new product versions begin to be released without support for 32bit operating systems, users wishing to evaluate Orion based products on a 32bit operating system are encouraged to contact Sales to obtain earlier product versions which support 32bit operating systems.

 

 

.NET 4.6.2

 

Current Orion product module releases, such as Network Performance Monitor 12.1 and Server & Application Monitor 6.4, require a minimum version of .NET 4.5.1. All future Orion product module releases built atop Core versions later than 2017.1 will require a minimum version of Microsoft's .NET 4.6.2, which was released on 7/20/2016. This version of .NET is also fully compatible with all current shipping and supported versions of Orion product module releases, so there's no need to wait until your next Orion module upgrade to update to this newer version of .NET. Subsequently, .NET 4.7 was released on 5/2/2017 and is equally compatible with all existing Orion product module versions in the event you would prefer to upgrade directly to .NET 4.7 and bypass .NET 4.6.2 entirely.

 

It's important to note that Microsoft's .NET 4.6.2 has a hard dependency on Windows Update KB2919355, which was released in May 2014 for Windows Server 2012 R2 and Windows 8.1. This Windows Update dependency is rather sizable, coming in between 319-690MB. It also requires a reboot before .NET 4.6.2 can be installed and function properly. As a result, if you don't already have .NET 4.6.2 installed, you may want to plan for this upgrade during your next scheduled maintenance window to ensure your next Orion upgrade goes smoothly and as quick as possible.

 

Minimum Memory Requirements

 

With many of the changes referenced above, minimum system requirements have also needed adjustment as well. Windows Server 2012 and later operating systems utilize more memory than previous versions. Similarly, .NET 4.6 can also utilizes slightly more memory than .NET 4.5.1. As we move forward however, 64bit processes inherently use more memory than the same process compiled for 32bit. To ensure users have a pleasurable experience running the next version of Orion products, we will be increasing the absolute minimum memory requirements from 4GB to 6GB of RAM for future versions of Orion product modules. The recommended minimum memory requirement however, will remain at 8GB.

 

While most readers themselves today would never consider running and using a Windows 10 laptop on a day-in-day-out basis with just 4GB of RAM, those same people also likely wouldn't imagine running an enterprise grade server based monitoring solution on a system with similar such specs either. If you do, however, find yourself in an environment running Orion on 4GB of RAM today, an 8GB memory upgrade can typically be had for less than $100.00. This can be done before the next release of Orion product modules and will even likely provide a significant and immediate improvement to the overall performance of your Orion server.

 

 

How to Prepare

 

All items listed above can be completed prior to the release of the next Orion product module versions and will ensure your next upgrade goes off without a hitch. This posting is intended to provide anyone impacted by these changes with sufficient notice to plan any of these upgrades during their regularly scheduled maintenance periods, rather than during the upgrade process itself. In-place upgrades of SQL, as stated above, are a fairly simple and effective process to get upgraded quickly with the least possible amount of effort. If you're running Orion on Windows Server 2008 or 2008 R2, in-place OS upgrades are also feasible. If either of these are not feasible or desirable for any reason, you can migrate your Orion installation to a new server or migrate your Orion database to a new SQL server by following the steps outlined in our migration guide.

 

Other Options

 

If for any reason you find yourself running Orion on Windows Server 2008, Server 2008 R2, or on SQL 2008/R2 and unable to upgrade, don't fret. The current releases of Orion product modules will continue to remain fully supported for quite some time to come. There is absolutely zero requirement to be on the latest releases to receive technical support. In almost all cases, you can also utilize newly published content from Thwack's Content Exchange with previous releases, such as Application Templates, Universal Device Pollers, Reports, and NCM Configuration Change Templates. When you're ready to upgrade, we'll be here with plenty of exciting new features, enhancements and improvements.

 

 

Planning Beyond The Next Release

 

At any given time, Orion supports running on a minimum of three major versions of the Windows Operating System and SQL database server. When a new server OS or SQL version is released by Microsoft, SolarWinds makes every effort possible to support up to four OS and SQL versions for a minimum of one Orion product module release. If at any time you find yourself four releases behind the most current OS or SQL server version, you may want to begin planning an in-place upgrade or migration to a new server during your next regularly scheduled maintenance window to ensure your next Orion product module upgrade goes flawlessly.

 

For your reference, below is a snapshot of Windows Operating Systems and SQL Server versions which will be supported for the next release of Orion product modules. This list is not finalized and is still subject to change before release. However, nothing additional will be removed from this list, though there could be additional version support added after this posting.

 

Supported Operating System VersionsSupported Microsoft SQL Server Versions
Server 2012SQL 2012
Server 2012 R2SQL 2014
Server 2016SQL 2016

PoShSWI.png

On a previous post I showed off a little PowerShell script that I've written to build my SolarWinds Orion Servers.  That post left us with a freshly imaged Windows Server.  Like I said before, you can install the O/S however you like.  I used Windows Deployment Services because I'm comfortable with it.

 

I used Windows Server 2016 because this is my lab and...

giphy.gif

 

Now I've got a list of things that I want to do to this machine.

  1. Bring the Disks Online & Initialize
  2. Format Disks & Disable Indexing
  3. Configure the Page File
  4. Import the Certificate for SSL (Optional)

 

Because I'm me, I do this with PowerShell.  I'm going to go through each of stage one by one.

Stage 0: Declare Variables

I don't list this because this is something that I have in every script.  Before I even get into this, I need to define my variables.  For this it's disk names and drive letters.

#region Build Disk List
$DiskInfo  = @()
$DiskInfo += New-Object -TypeName PSObject -Property ( [ordered]@{ DiskNumber = [int]1; DriveLetter = "D"; Label = "Page File" } )
$DiskInfo += New-Object -TypeName PSObject -Property ( [ordered]@{ DiskNumber = [int]2; DriveLetter = "E"; Label = "Programs" } )
$DiskInfo += New-Object -TypeName PSObject -Property ( [ordered]@{ DiskNumber = [int]3; DriveLetter = "F"; Label = "Web" } )
$DiskInfo += New-Object -TypeName PSObject -Property ( [ordered]@{ DiskNumber = [int]4; DriveLetter = "G"; Label = "Logs" } )
#endregion

 

This looks simple, because it is.  It's simply a list of the disk numbers, the drive letter, and the labels that I want to use for the additional drives.

Stage 1: Bring the Disks Online & Initialize

Since I need to bring all offline disks online and choose a partition type (GPT), I can do this all at once.

#region Online & Enable RAW disks
Get-Disk | Where-Object { $_.OperationalStatus -eq "Offline" } | Set-Disk -IsOffline:$false
Get-Disk | Where-Object { $_.PartitionStyle -eq "RAW" } | ForEach-Object { Initialize-Disk -Number $_.Number -PartitionStyle GPT }
#endregion

 

Stage 2: Format Disks & Disable Indexing

This is where I really use the variables that are declared in Stage 0.  I do this with a ForEach Loop.

#region Create Partitions & Format
$FullFormat = $false # indicates a "quick" format
ForEach ( $Disk in $DiskInfo )
{
    # Create Partition and then Format it
    New-Partition -DiskNumber $Disk.DiskNumber -UseMaximumSize -DriveLetter $Disk.DriveLetter | Out-Null
    Format-Volume -DriveLetter $Disk.DriveLetter -FileSystem NTFS -AllocationUnitSize 64KB -Force -Confirm:$false -Full:$FullFormat -NewFileSystemLabel $Disk.Label
    
    # Disable Indexing via WMI
    $WmiVolume = Get-WmiObject -Query "SELECT * FROM Win32_Volume WHERE DriveLetter = '$( $Disk.DriveLetter ):'"
    $WmiVolume.IndexingEnabled = $false
    $WmiVolume.Put()
}
#endregion

 

We're getting closer!  Now we've got this:

DiskConfiguration.png

 

Stage 3: Configure the Page File

Getting the "best practices" for page files are crazy and all over the board.  Are you using flash storage?  Do you keep it on the O/S disk?  Do you declare a fixed size?  I decided to fall back on settings that I've used for years.

Page file does not live on the O/S disk.

Page file is statically set

Page file is RAM size + 257MB

In script form, this looks something like this:

#region Set Page Files
$CompSys = Get-WmiObject -Class Win32_ComputerSystem -EnableAllPrivileges
# is the system set to use system managed page files
if ( $CompSys.AutomaticManagedPagefile )
{
    # if so, turn it off
    $CompSys.AutomaticManagedPagefile = $false
    $CompSys.Put()
}
# Set the size to 16GB + 257MB (per Microsoft Recommendations) and move it to the D:\ Drive
# as a safety-net I also keep 8GB on the C:\ Drive.
$PageFileSettings = @()
$PageFileSettings += "c:\pagefile.sys 8192 8192"
$PageFileSettings += "d:\pagefile.sys 16641 16641"
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\" -Name "pagingfiles" -Type multistring -Value $PageFileSettings
#endregion

 

Stage 4: Import the Certificate for SSL (Optional)

Since this is my lab, I get to do what I want.  (See above)  I include using SSL for Orion.  I have a wildcard certificate that I can use within my lab, so if I import it, then I can enable SSL when the configuration wizard runs.  This certificate is saved on a DFS share in my lab.  This is the script to import it.

#region Import Certificate
# Lastly, import my internal PKI Certificate for use with HTTPS
$CertName = "WildcardCert_demo.lab"
$CertPath = "\\Demo.Lab\Files\Data\Certificates\"
$PfxFile = Get-ChildItem -Path $CertPath -Filter "$CertName.pfx"
$PfxPass = ConvertTo-SecureString -String ( Get-ChildItem -Path $CertPath -Filter "$CertName.password.txt" | Get-Content -Raw ) -AsPlainText -Force
Import-PfxCertificate -FilePath $PfxFile.FullName -Password $PfxPass
#endregion

 

That's it.  Now the disks are setup, the page file is set, and the certificate is installed.  Next, I rename the computer, reboot, run Windows Updates, reboot, run Windows Updates, reboot, run Windows Updates... (you see where this is going, right?)

 

Execution Time: 16 seconds

Time saved: at least 15 minutes.

 

There's still some prep work I can do via scripting and I'll provide that next.

 

This is a cross-post from my personal blog post Building my Orion Server [Scripting Edition] – Step 2 – Kevin's Ramblings

Filter Blog

By date: By tag: