If you've been using the SolarWinds® Orion® unified IT monitoring platform for more than a few years, it's likely that you've at least once migrated it to a new server. You may have migrated from a physical server to a virtual one, or perhaps you simply needed to migrate to a server running a more modern operating system. Regardless of the reason, you're likely aware that there's a litany of documentation and training videos on the subject. Below are just a few, in case you’re curious.

 

 

Index

 

Deprecation

 

Now, as many of you have likely discovered during your last upgrade to SolarWinds® Network Performance Monitor (NPM) 12.3, SolarWinds® Server & Application Monitor (SAM) 6.7, or any other product modules released in 2018, support for Windows Server 2012, Server 2012 R2, and SQL Server 2012 were officially deprecated in those releases. You may have stumbled upon that when reviewing the release notes, or during the pre-flight checklist when running the installer.

 

Deprecation does not mean that those versions aren’t supported with Network Performance Monitor 12.3, Server & Application Monitor 6.7, etc. Deprecation simply means that new versions released in the future are unlikely to support those older operating systems. These deprecation notices were added at the request of customers like yourself, who asked to be provided with advance notice when future versions of Orion product modules would no longer run on older operating systems or SQL database versions. Those deprecation notices serve to allow customers an opportunity to budget and plan for these changes accordingly, rather than find out during a 3 a.m. change window that the upgrade you planned doesn't support your current OS or database version.

 

While future product module versions may no longer support Windows Server 2012, Server 2012 R2, or SQL Server 2012, that doesn't mean all previous versions are no longer supported at all. In fact, the latest, currently shipping versions of NPM, SAM, and other SolarWinds products are planned to continue to support running on Windows Server 2012 and 2012 R2 for many more years to come. So, if you're happy with the versions of product modules you're running today, take your time and don't rush your OS upgrade or server migration. Plan it appropriately. We'll still be here, waiting with a boatload of awesome new features whenever you're ready to upgrade.

 

Preface

 

But I digress. Since many of you have planned, or will eventually be planning, to migrate your Orion Platform to Server 2016 or perhaps even Server 2019, this inevitably stirs up painful memories of migrations you have undoubtedly done in the past—whether that was the Orion Platform specifically or some other mission-critical system in your environment. Let's face it, these migrations are typically neither fun or easy. Luckily, we’ll discuss how you can help change that.

 

Now, over the years, I have performed countless Orion Platform upgrades and migrations. And I, like many of you, have amassed a tremendous treasure trove of tips and tricks for streamlining the process down to an art form. The name of the game here is called downtime, and the less of it you can incur during your migration the sooner you get to go home, and the more you look like a rock star to your boss. What I'm about to show you here is how you can migrate your Orion Platform server with zero downtime!

 

As I stated above, there is a wealth of information on the subject of migrating the Orion Platform to a new server, and perhaps I overstated it a bit when I suggested that you're doing it wrong. There are multiple different (yet still correct) ways of migrating the Orion Platform from one server to another, and some ways may be faster, easier, or less error prone than others. These migrations typically vary depending upon the type of Orion server role the machine is hosting. This blog post focuses on the main Orion server, but the strategy can apply equally to Additional Polling Engines.

 

Orion Server Migration Made Easy

 

Going forward I'll assume you have at least one Orion server running NPM 12.0.1 or later—that one server being the main Orion server itself. If you're still running NPM 11.5.x, then chances are good you're not planning to migrate directly to Server 2016 or Server 2019 anyway, since 11.5.x isn't supported on either of those operating systems. I'm also going to assume that your Orion Platform server is currently running on Server 2012 or 2012 R2, though this process is equally applicable to those still rocking Server 2008 or Server 2008 R2. I'm also going to assume you have another freshly installed server ready for your Orion Platform migration. Lastly, this document won't be covering database server migrations. If that's what you were hoping for, there's an excellent document on the subject here.

 

First Things First

As with any good do-it-yourself project, the first order of business is to throw out, or otherwise lose, the instructions. I'm going to be walking you through what I’ve found to be the simplest, fastest, least error-prone manner of migrating the Orion Platform to a new server with absolutely zero downtime. None of those other documents or videos referenced above are going to show you how to do that, so let's just pretend they never existed.

 

Schedule Your Maintenance Window

While the Orion server should not be going down during the migration, it's always best to plan for the worst and hope for the best. I don't want anyone telling their boss that they decided to migrate their Orion server in the middle of the day because some guy on THWACK® named aLTeReGo told them to do it.

 

Backup Your Orion Server

Conventional wisdom would tell you that if it can go wrong, it probably will—so be prepared. If your Orion server is running on a virtual machine, take a snapshot prior to the migration just in case. While we won't be messing with that server at all during the migration, it's always good to have a safety net just in case.

 

 

Backup Your Orion Database

I can't emphasize this enough. BACKUP YOUR DATABASE! Seriously, just do it. Not sure if the backup from last night completed successfully? Do another one. Everything important is in the database, and with a backup, you can restore from virtually any disaster. If the database is corrupted though and you don't have a good backup to restore from, you may be rebuilding your Orion Platform again from scratch. You don't need to shut down the Orion Platform to take a backup, so go ahead and take another just to be on the safe side. We'll wait.

 

Need a little extra insurance? Why not give SolarWinds cloud-based server backup a try?

 

 

Do Not Upgrade (Yet)

If you’re migrating as part of an upgrade, don't upgrade yet unless you’ll be migrating to Windows Server 2019. It's best to leave the original server fully intact/as-is in the event something goes wrong and you need to roll back. There will be plenty of time to upgrade and play with all the cool new features later. For now, just focus.

 

 

Have Faith and Take a Deep Breath

This is going to start off a bit odd, but stick with me and we'll all come out of this together. Start by going to [Settings > All Settings > High Availability Deployment Summary] in the Orion web interface from a web browser on the new machine where you plan to migrate the Orion Platform. Next, click [Setup a New HA Server > Get Started Settings Up a Server > Download Installer Now].

 

Download the High Availability Secondary Server Installer

 

 

That's right, we'll be using the power of Orion High Availability (HA) to perform this Orion server migration. If at this point you're worried that you can't take advantage of this awesome migration method because you don't own an Orion High Availability license, fret not. Every Orion Platform installation comes with a full 30-day evaluation of High Availability for use on an unlimited number of servers. That's more than enough time for us to complete this migration! If you have no need for Orion High Availability, don't worry. The final steps in this migration process include disabling High Availability, so there's no requirement to purchase anything. However, you might find yourself so smitten with Orion High Availability by the end of the migration that you may wonder how you ever managed to live without it. You've been warned!

 

Begin Installation On Your New Orion Server

Once downloaded, double-click on the Scalability Engines Installer. Depending on which version of the Orion Platform you're running, the Scalability Engines Installer may look significantly different, so I've included screenshots below from both versions. On the top row, you’ll see screenshots from the Scalability Engines Installer version 1.x and version 2.x below that. Regardless of which version you're running through, the end result should be identical.

 

Connect to Existing Orion Server on Original Server

Select Server Role to Install

 

Once the installation is complete, the installer will walk you through the Configuration Wizard process. Ensure that all settings entered in the Configuration Wizard are identical to those used by your existing Orion server.

 

Let The Fun Begin

 

Now that we've installed a secondary Orion server, it's time to join them together into a pool (aka cluster). To do this, we begin by logging into the Orion web interface on your original Orion server. From there go to [Settings -> All Settings -> High Availability Deployment Summary]. There, you should find listed your original Orion server that you're logged into now, as well as your new Orion server that you just installed in the steps above. Click the “Set up High Availability Pool” button next to the name of your new Orion server.

 

Now, if both your existing Orion server and the new server you'll be migrating to are located on the same subnet, you might be prompted to enter different information within the HA Pool creation wizard. It's also important to note that if you're currently running Orion Platform 2017.1 or earlier, it will not be possible to perform this zero-downtime server migration, unless both your existing and new Orion servers are located on the same subnet.

 

Same Subnet Migration

 

If both your existing and new Orion servers reside on the same subnet, you’ll be prompted to provide a new, unused IP address on the same subnet as your existing Orion server. This virtual IP (VIP) will be shared between these two Orion servers, as long as they remain in the same HA Pool. The purpose of the VIP is to route traffic to whichever member in the pool is active. If you don't have intentions of keeping HA running after the migration, this IP address will be used only briefly and can be reclaimed at the conclusion of the migration. When you're done entering the IP address, click “Next”.

 

Migrating to Server in Different Subnet

 

If you're migrating to an Orion server on a different subnet than your existing one, then the HA Pool creation wizard will prompt you to provide a virtual hostname rather than a virtual IP address. This name helps ensure users are directed to the “active” member in an HA pool when accessing the Orion web interface whenever failovers occur. If you don't have intentions of keeping HA running after the migration, you can enter anything you like into this field. Once you've populated the “Virtual Host Name” field, click “Next.”

Close

On the “DNS Settings” step of the HA Pool creation wizard, select your DNS server type or choose “other” from the “DNS Type” drop-down menu if you don't intend on keeping HA running after the migration. If you choose “other,” you can populate any IP address and any DNS zone (even one that doesn't exist) into the fields provided—these values will not be used unless you plan to integrate Orion High Availability with a non-Microsoft and non-BIND DNS server in the future.

 

When complete, click “Next” to proceed, review the “Summary,” and click the “Create Pool” button to complete the HA Pool creation process.

 

Ready, Set, Cut-over!

 

From the Orion Deployment Summary [Settings > All Settings > High Availability Deployment Summary], select the HA pool you just created. On the right side, click the “Commands” drop-down menu and select “Force Failover.” This should initiate an immediate failover from your old Orion server to your new one. Note that while the cutover time for polling and alerting is typically just a couple of seconds, it may take the Orion web interface a minute or so before it's fully accessible. Unless you were accessing the Orion Web Console using the VIP you assigned earlier, you’ll need to change the URL in your browser to point to the IP address of the new Orion server or the VIP to regain access to the Orion web interface once you've initiated the failover.

 

Fore Failover.png

Verify you're cut over to the new server by looking at the pool members listed on the Orion Deployment Summary, specifically their state or roll showed just below their names. Your old Orion server should be listed as “Standby,” and your new Orion server should display as “Active.” Congratulations! You've just completed a successful Orion server migration with zero downtime!

 

Clean-up

 

The following steps should be completed within 30 days if you don't currently own or have plans to purchase Orion High Availability to provide continuous monitoring, redundancy, and near-instantaneous failover of your Orion server in the event of a failure. Don't forget that Orion High Availability also helps you maintain that your Orion Platform’s 100% uptime every month when Patch Tuesday rolls around. (Patch Tuesday… or, you know, when Microsoft releases its latest round of operating system hotfixes, all of which inevitably require a reboot.)

 

Shutdown Old Server

 

You should start the cleanup process by shutting down your original Orion server. It served you well, and we all know how hard it is to bid a final farewell to such a loyal friend, but its time has come. If you're not immediately planning to destroy the virtual machine or de-rack your old Orion server, you may first want to consider changing its IP address if you plan to use it on your new Orion server. This will ensure that if the old Orion server is started back up, it won't cause an IP address conflict and wreak havoc on your network monitoring. Once you've changed the IP address, resume with shutting down the server before proceeding with the next steps.

 

 

Remove The Pool

 

From within the Orion web interface, navigate back to the High Availability Deployment Summary by going to [Settings > All Settings > High Availability Deployment Summary]. Click on the name of the Pool you created earlier in the steps above. From the “Commands” drop-down menu on the right select “Remove Pool.”

 

 

Reclaim The Original Orion Server's IP Address

 

Last, but certainly not least, you may want to reclaim the IP address of your original Orion server by assigning it to your new Orion server. This is simply a matter of logging into the Windows server via RDP (or etc.) and opening the Network Control Panel. I prefer to go to the “Run” command and typing “ncpa.cpl” and <Enter> to open the Network Control Panel without needing to navigate around Windows. Once you've opened the Network Control Panel, right-click on your network interface and select “Properties.” Within the interface properties, select “Internet Protocol Version 4 (TCP/IPv4)” and click “Properties.”

 

Network Control PanelInterface Properties

 

Update the “IP Address” field by entering the IP of your original Orion server, then click “Advanced.” In the “Advanced TCP/IP Settings,” you’ll find the Virtual IP Address you configured earlier in the steps above—you should be able to safely remove this now. To do so, simply select it by clicking on the IP address with your mouse and then click the “Remove” button. Then, click “OK” on each of the three windows to save your changes.

 

TCP/IP PropertiesAdvanced TCP/IP Settings

 

Update DNS/Machine Name

 

Do not rename the server itself in Windows. If you have users who are accessing the Orion Web Console via the original server’s name, the best and easiest method of ensuring those users can now access the new server is to create a DNS C-Name that points to the new server. It's always a good idea to have a layer of abstraction between what name end users type into their browser and the name of the server itself. This can help ensure that you can easily redirect those users later, should you want to add an Additional Web Server or re-enable High Availability. To accomplish this, we are going to create a DNS CNAME record for your original Orion server's name that points to the new Orion server. In this example, I'm using Windows DNS, but the same principle applies for really any type of DNS server.

 

From the DNS Control Panel on your DNS Server, expand “Forward Lookup Zones” and right-click on your domain name and select “New Alias (CNAME).” In my example below, my previous server's FQDN (Fully qualified domain name) was “solarwinds.sw.local” and my new Orion's server name is “pm-aus-jmor-04.sw.local.” In the “Alias name” enter “solarwinds.” The “Fully qualified domain name” field will automatically populate with the alias and domain name. In the “Fully qualified domain name (FQDN) for target host” field, enter the FQDN of your new Orion server and click “OK” to save your changes. Lastly, find and delete the ANAME “Host (A)” record for your old Orion server.

 

DNS Control PanelAdd New Alias (CNAME)

 

While this undoubtedly looks like a lot of steps, the process is actually fairly straightforward and I completed it in less than an hour. Now, obviously your mileage may vary, but regardless of how long it may take, there's no simpler way—for which I'm aware—that will allow you to migrate your Orion Platform to a new server with anywhere close to zero downtime. Hopefully, this process will save you a fair bit of time and frustration over the previous methods referenced above. If you have any tips and tricks of your own that have simplified your Orion server migrations, feel free to post them in the comments sections below—we'd love to hear them!

 

The SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates.  All other trademarks are the property of their respective owners.

As awesome as SolarWinds applications can be at helping avoid a network crisis, sometimes disaster strikes closer to home: in the Orion® Platform itself. You come in to work one morning and click on the web page, only to see an unhandled exception, or you realize you haven’t seen an alert in a suspiciously long time, or you plan an upgrade expecting everything to go smoothly and find yourself stumped by a configuration wizard error. While our awesome support folks are here to help you get past any trouble you might run into, wouldn’t it be great if you had a way to check the health of your SolarWinds environment to prevent a catastrophe?

Well, good news: now you do! Introducing the Orion Health page, designed to help you keep your SolarWinds environment humming along trouble-free. You can go to Settings -> All Settings -> High Availability Deployment Summary (found in the Product Specific Settings section). Once there, you will see a tab called Deployment Health (and don’t worry, even if you don’t use our High Availability product, you still have these options).

 

This page has over 70 checks created from analyzing the most common reasons why customers call us. We cover everything from database maintenance to disk space. The best part is, you don’t have to remember to come to this page and run the server health checks regularly—they will run every night along with our regularly scheduled database maintenance. We run specific tests against each server in your deployment. Got an additional web server? A scalability engine? A standby server? We got you covered!

 

Shhh…

Of course, every environment is different, and we know that some tests might not apply to everyone. For example, we’ll warn you that if your SQL Server is on a VM, that might not be the best setup.  Sometimes resource-intensive applications like SQL don’t play well with shared resources. But if you know that your VM is a beast and can handle whatever we can throw at it, you can just silence that particular check:

You won’t see it again unless you un-silence it, so your daily view will be only the tests you care about.

 

There’s a KB for that!

So now you’re using the health page to keep everything copacetic, and you find a failure that you’re not quite sure what to do with.  Well, we’ve got a whole database full of Knowledge Base articles right at your fingertips! Just click on the arrow at the end of the row with the test on it, and a panel will pop up with a description of the test and a link to an article with more info.

 

 

Now that you have this tool at your fingertips, remember that we always welcome your feedback. Think there’s something we could test for that we don’t? Something that needs to be tweaked? Let us know and we’ll be happy to take a look!

Hi, all! Welcome back to the continuation of our Primer posts on SWQL and the Orion® SDK. In the last post, we established how to create a query, and how to link tables together to get useful information. In this post, we’re going to discuss how to apply these to your Orion Platform products.

If you don’t feel entirely comfortable creating a query, I highly encourage you to read over the last post. It serves as a foundation for today’s discussion.

 

Reports:

The first and most obvious application for SWQL queries is generating Orion reports in the web-based report writer. To start, go to Reports à All Reports, then select “Manage Reports” in the upper right corner:

 

 

From here, click on “Create New Report”:

 

 

If this is your first time creating any report, you will see a nice splash page on how to create reports. I highly recommend you read it over to get an idea of the process, and when you’re finished, go ahead and close to proceed with the remaining steps.

 

The first page you see when you create a report is Add Content. For what we’re doing, there really are only two options, Custom Chart and Custom Table. Since we’re going to use the example from the previous post, let’s select the “Custom Table” option.

 

 

Once selected, you are asked to add your data source. This is where our SWQL magic comes into play; change the Selection Method from “Dynamic Query Builder” to “Advanced Database Query (SQL, SWQL)”:

 

 

Make sure the radio button is set to “SWQL” so Orion knows which language to construct from. From here, let’s copy and paste our query from the previous post into the big box. Then click on “Preview Results” to make sure everything is working correctly. Note: this will not show you all results, just a small selection:

 

 

Once that’s complete, click “Add to Layout,” which will automatically send you to the custom table formatting table. Here you can add the columns from your query into the report:

 

 

 

Now that your columns are added, you’ll see the table layout section. Use the dotted icons to arrange the columns in any order you want (1). You can also expand on the column to change their name (2) to something friendlier, such as “System Name” instead of “Caption” (3):

 

 

Once you’re finished, click “Submit” to finish the table. If you wish to add more tables, or if you charted something, you can add more resources to the page. Otherwise, you can finish your report as you would normally.

 

That wraps it up for now. Next time we’ll continue exploring how to apply SWQL queries into widgets in the dashboard. Thanks for reading!

Doing more with less seems to be a staple of working in IT today.  Part of that also includes doing more with the existing tools at your disposal or adding tools to make your job easier, giving you back your well-earned free time.  For IT professionals, getting the information into a network monitoring software (NMS) solution is only the first step in the battle.  Deciding how to work with that information is the next phase in your evolution as a monitoring professional.

 

It's no secret that I was a customer before I come to work for SolarWinds.  As a former customer, I tried my best to make sure that my monitoring solution did as much of the heavy lifting for my organization as possible.  In my eyes, what good was a system that just alerted me to problems without actively trying to correct those problems?  Were the metrics important to specific teams being shown in the proper light to guide business decisions?  Were our help desk and IT teams properly informed about the state of the infrastructure? These are just a few of the questions that I asked myself on a near daily basis.  Making tweaks and updates to the NMS became a process of care and feeding for the solution.  Thankfully, I had the THWACK® community and the plethora of content therein to help guide me, but every environment is different.  I often thought it would be nice to be able to get first-hand information and ask questions of the experts about my situation.

 

I've spoken at multiple SolarWinds User Groups (SWUGs) about the ways to help optimize and scale out your build, streamline your support and monitoring processes, isolate and pinpoint the root cause of issues, eliminate noise in your alerting, and leverage the data collected to make informed decisions.  Any one of these can help you do more with what you already have.  The more feedback we get from the community, the more resources we can provide to give you back your weekends.  We've listened, and that's part of what makes THWACKcamp so epic.

 

This year, THWACKcamp is packed full of knowledge bombs that can help you do your job better, more efficiently, and with less stress.

 

If you are thinking about working towards automating your infrastructure, take what you've learned and leverage the SolarWinds Orion API with “There's an API for That: Introduction to the SolarWinds Orion SDK.”  We are even including our code samples (here, here, and here) so that you can play along with the home game.

 

There's an API for That: Introduction to the SolarWinds Orion SDK

Repetitive tasks are boring and repetitive. Why do we have computer systems if not to make our lives easier? In this session, learn why we want to leverage the SolarWinds® Orion API to do just that with me and fellow THWACK MVPs Leon Adato and Zack Mutchler.

 

Do you have a large or growing deployment and are worried about optimizing your build?  There's a session just on “Optimizing Orion.”

Optimizing Orion

In this session, we will help you understand how to optimize your Orion® Platform. We will discuss topics such as when to know if you should scale up or scale out, and how to identify issues with your current Orion installation.

 

Are you struggling from beneath a pile of unnecessary alerts and are trying to find the light?  Why not have your alerts work for you, instead of against you?  “Alerts, How I Hate Thee” is the session for you.

Alerts, How I Hate Thee

Many IT professionals believe if you can't get an alert when something is going wrong, why monitor at all? Yet alerting is also seen as a curse, a source of constant interruptions, false alarms, and “noise.” In reality, it can be so much better. Well-crafted alerts based on insightful monitoring are a benefit to the business and a gift to the recipient, saving hours of investigation and thousands of dollars. Whether alerts are a blessing or a curse depends largely on their design and implementation (more so than any specific monitoring tool or technique) and thankfully, good design can be taught and learned. In this session, we'll take a brief tour of the alerting hall of horrors, and then look at real-world, vendor-agnostic techniques to make alerts meaningful, effective, valuable, and actionable.

 

Is it time to get the biggest bang for your bits with your NMS, it's probably useful to take peruse the goodness during “Tips & Tricks: Thinking Outside the Box

Tips & Tricks: Thinking Outside the Box

Making its third round at THWACKcamp, this popular session covers the tips and tricks of our beloved SolarWinds products that are a way of life for me and Head Geek Destiny Bertucci. Combined forces makes for some great tips and tricks that help you to think outside of the box for your day-to-day monitoring needs. There are always ways to create solutions with just a little tweaking to make your SolarWinds products be the highlight in any organization.

 

The best part about a THWACKcamp session?  They are completely free for everyone – you just need to sign up, select your sessions, and then sit back and absorb all the nerdy goodness online. Plus, if you watch live, you can join the chat and ask questions of the experts while the session is happening. What are you waiting for?  Sign up now!

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.