nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

License upgrade... Do I really have to reinstall?!?!?

anachronism

Ok, we have to upgrade our system from SL2000 to SLX, I have the upgrade, but this seems to be a complete new install!?!?

I just want to upgrade, with little (preferably no) downtime, but if I have to install a new version this isn't going to happen. I'm also concerned that if I install when my hot standby is running, that changes in our backend database cluster will cause issues.

Why do I have to re-install? I've never come across such an absurd license upgrade process before (doesn't seem particularly enterprise friendly!). I'd expected a key file that had to be dropped somewhere, not a complete new set of binaries. It must be a lot of fun trouble-shooting if all your licenses involve subtle code changes! Not to mention the headache I now have... should I install direct to production untested code (in our environment... how much has changed? Will my db customisations be lost... sooo much hassle just to upgrade a license!)? I don't like installing new code (however minor the changes might be) without going through a staging environment. Suddenly my urgent need to upgrade is turing into a long project!

Any advice on how to make this less painful than it seems to be? After a long period of dislike for solarwinds, I was starting to be won round slightly by the flexibility it offered when I was working on our customer portal. This has set my opinion right back.

Find more posts tagged with

Accepted answers

All comments

chris.lapoint

We completely understand your frustration and we have plans in place to make this a seamless process moving forward.

We're moving all Orion products to new licensing, which allows for activation keys to be used to upgrade license tiers without the need to reinstall. New licensing also allows you to install an eval of one of our products and license the eval without having to install the product bits over the top.

So far, all Orion modules (APM, IPAM, NTA, IP SLA) have moved to new licensing. Orion NPM and NCM are still on old licensing, but we expect to move them later this year.

So, the good news is this won't be a pain for much longer. For now though, you'll need to install the SLX production bits over the SL2000 production bits. As long as they're both the same version, the only thing that will change is the license files built into the apps.

Please contact support if you have any questions and they can assist you with steps to mitigate any downtime.

anachronism

Does this mean that monitoring via my hotstandby when upgrading to SLX is an approved and tested solution? If this is the case, I simply have to install APM/ALX onto my standby (this is free now on my standby, as I have one license for my main server?).

If this is a simple change of license files in the app, can this not be done more rapidly by just copying over affected files. I am _REALLY_ concerned about re-building our solution and the mop up work I'll have to do after. This is insane for a license upgrade. Realistically, is there anyway I can run a test upgrade on a lab VM to see how it goes before-hand (I'm guessing not, as I won't be able to license that)?

<rant>

I saw a post from last year saying this was going to be fixed (March 23rd, so nearly exactly a year ago, much like the debacle with VMWare 4 monitoring, which was really important for a long time, but didn't appear! We cannot run our business on promises), and yet we still have this broken upgrade procedure (sure I guess it's there to protect your IP, at the expense of your customers! I really don't see why anyone would release software with such a fatal flaw). I know you guys don't like to publish any sort of commitments on when things get fixed, but my boss does tend to like that sort of information, and it's something we get from our other vendors (they don't always deliver on time, but it's got to be better than, it'll get fixed some time, they were talking about fixing it a year ago!). I know I'll get push back on even the small amount of expenditure in upgrades and support renewals because of issues like this. I really would urge a re-think on this policy of not committing to upgrades or timescales.

</rant>

Sorry, had to get that off my chest, it is really annoying and I would imagine is a big issue for a lot of your customers who actually have to deliver projects to a plan/timescale (which is probably most of us).

byrona

I thought I should point out to you that currently as far as I am aware the hot standby system doesn't cover APM when you fail over to it. The hot standby system only covers things monitored by NPM.

chris.lapoint

Does this mean that monitoring via my hotstandby when upgrading to SLX is an approved and tested solution? If this is the case, I simply have to install APM/ALX onto my standby (this is free now on my standby, as I have one license for my main server?).
If this is a simple change of license files in the app, can this not be done more rapidly by just copying over affected files. I am _REALLY_ concerned about re-building our solution and the mop up work I'll have to do after. This is insane for a license upgrade. Realistically, is there anyway I can run a test upgrade on a lab VM to see how it goes before-hand (I'm guessing not, as I won't be able to license that)?

I'm checking on this, but I'd recommend getting some advice from support before you perform the upgrade.

<rant>
I saw a post from last year saying this was going to be fixed (March 23rd, so nearly exactly a year ago, much like the debacle with VMWare 4 monitoring, which was really important for a long time, but didn't appear! We cannot run our business on promises), and yet we still have this broken upgrade procedure (sure I guess it's there to protect your IP, at the expense of your customers! I really don't see why anyone would release software with such a fatal flaw). I know you guys don't like to publish any sort of commitments on when things get fixed, but my boss does tend to like that sort of information, and it's something we get from our other vendors (they don't always deliver on time, but it's got to be better than, it'll get fixed some time, they were talking about fixing it a year ago!). I know I'll get push back on even the small amount of expenditure in upgrades and support renewals because of issues like this. I really would urge a re-think on this policy of not committing to upgrades or timescales.
</rant>

See this post for a detailed explanation of our position on roadmaps.

It's important to understand that Orion has used this licensing framework for over 10 years, so it's not a simple rip and replace, especially given the size of the Orion customer base. We take these kinds of fundamental changes very seriously and it's important to us to make sure it's as seamless as possible for our customers. While the old licensing wasn't ideal for the upgrade version use-case, it has been extremely stable which I'm sure you'd agree is critical to any licensing engine. So, we took some time over the past year to ensure that new licensing was also stable and met expectations before we made the switch with our flagship product. This meant starting with modules first. I hope this makes sense and that you'll bear with us in the interim.

I'm hoping that other customers can add their experiences from their upgrade of license tiers to help make you feel more comfortable with this process.

anachronism

I know APM doesn't have a hot standby failover mechanism, but I thought a least if it was installed, it could be manually failed-over? Is this not the case? Does the recent license change allow for this?

anachronism

See this post for a detailed explanation of our position on roadmaps.
It's important to understand that Orion has used this licensing framework for over 10 years, so it's not a simple rip and replace, especially given the size of the Orion customer base. We take these kinds of fundamental changes very seriously and it's important to us to make sure it's as seamless as possible for our customers. While the old licensing wasn't ideal for the upgrade version use-case, it has been extremely stable which I'm sure you'd agree is critical to any licensing engine. So, we took some time over the past year to ensure that new licensing was also stable and met expectations before we made the switch with our flagship product. This meant starting with modules first. I hope this makes sense and that you'll bear with us in the interim.
I'm hoping that other customers can add their experiences from their upgrade of license tiers to help make you feel more comfortable with this process.

Ok, I've read that, and can't begin to tell you how much I disagree with it, sorry. Everyone should always realise in there interactions with the world that deadlines/agreements etc. are subject to change. That is the nature of a less than perfect world. However, to plan in a less that perfect world, we try to impose order. Try to plan. That's how we as individuals plan. Sure, we've all had meetings arranged just the day before cancelled with 5 minutes (or less!) notice, and it's annoying. Personally I find it more annoying when people won't commit to defined timescales I can try to plan around (companies who will visit for a short meeting on "Monday".. that's no use, how do I plan that? Ok, I've got to be there for the one hour they'll be there, what do I do with the rest of the time... just wait? Who controls this relationship? The supplier or the customer?). Sure it would be annoying to be promised continually, and to be continually let down, that would hurt your brand, but that's surely a matter of project management applying adequate contingency, and working to a plan?

Seriously, your customers are businesses. I guess you want to go after bigger businesses (more cash to spend, requirement for larger licenses, etc). The bigger the business, the more planning is required. Entropy increases, so more planning and control is required. To be honest, I find that blog post a cop-out. You could say that proper QA delays release, so why attempt to do it as well? I find the start of that post most revealing "...you're probably a geek as well". Yes, we as geeks find the whole PM thing annoying at time, but it's there for a reason! My boss for example, he doesn't find it annoying, he finds it very useful... He's also the one who has final say on what we buy.

As for the accounting rules, I must admit I know nothing about those, but as a lot of other companies operating in your space and country manage it, I can only assume it's not an insurmountable problem if you want to get around it.