Hi Doug,
Could you possibly clarify if it is enough to upgrade the core AR Server to
8.1 (not ITSM) in order to benefit from the new and generous 8.1-policy of
Application licenses in the Overview Console?
If so, does it apply both to ITSM 7.6 and 8.0?
I presume that the Overview-Console-ARDBC-Plugin needs an upgrade as well...
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Folks,
>
> As LG has noted, the “flaw” was not an error or bug in the implementation
> about how floating licenses work. But, it was more of an unintended cross
> consequence where BMC made the decision that we didn’t want to trigger the
> side effect of grabbing a bunch of application floating tokens just because of
> a query to the application to get a list of items for a console – especially
> when there may often not have been any items from that application to show in
> the first place for the user. So, in order to allow for the more effective
> interaction of the applications through a console without the side effect that
> was occurring, we considered it a “flaw in the intention” of the overall
> goal of licensing and so we reacted to the customer input and made the console
> no longer trigger obtaining licenses.
>
> As for how the licenses work, as folks have noted, it is a business decision
> about the behavior of licensing. If you look at most products, you either
> need a license just to use the product – there is no concept of a no license
> “read” user that BMC Remedy has. And, then many others have no concept of
> a “floating” license and all users are either “fixed” or
> “unlicensed” (with whatever unlicensed means). Finally, for those that do
> have floating licenses, you will not find products that let you use the
> product, then suddenly change your license to another type, and then release
> it back to let someone else use it all within minutes (I would be interested
> to see any product on the market that folks think have a floating license
> model that does this). So, really, the licensing is not as odd or unusual as
> folks think. Most of the time, it is the flexibility and variety of access
> with lots of unlicensed access allowed that causes the questions.
>
> Again, BMC has always been open to discussions about point areas where the
> spirit of the licensing is not being obeyed. This console example is a poster
> child for that. Although it was performing correctly and according to the
> rules, a decision was made to allow an exception as it was not the intention
> or goal to grab a bunch of application licenses just because of a console.
>
>
> As for can others do this? The answer is no. We allow violations of
> licensing models when there is a determination that the intention/goal of the
> model is not being met – another example is approvals where you do not need
> to have an application (or even an AR System license) to approve things that
> are assigned to you when you are working with approvals and BMC product. So,
> you don’t have to suddenly have everyone in the org who can approve having
> to have a license just to do approvals – even though they are writing to the
> system by doing an approval. For these cases, we take advantage of some
> exception logic that is built into the system to allow for these types of
> exceptions that is available only to BMC (since it is allowing violation of
> the licensing model, BMC can violate our own model but others cannot).
>
> Doug Mueller
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
> Sent: Monday, November 02, 2015 10:21 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Serious flaw in BMC Remedy Licensing
>
> **
> John,
> As you know, I'm not a BMC employee...so all of my understanding of things
> comes from that perspective :)
>
> As I understand it the overview console utilizes a plugin to pull the
> information...but, being I don't run ITSM where I work...I can't confirm
> this....but even with that said...even if the plugin was pulling the
> information...it's the SERVER that determines what type of allocation is
> made...so....if I were to guess, and this is 100% a guess...I would guess that
> something was re-written in the server that says something along the lines of
> 'if the query is coming in from 'this client' and the user is floating...don't
> allocate a write token'....and I would assume, that the 'this client' portion
> of that is specified using the client type function when that plugin
> connects....
>
> So...trying to replicate it would be difficult....but in theory not
> impossible....
>
> On Mon, Nov 2, 2015 at 11:02 AM, John Sundberg
> <john.sundb...@kineticdata.com<mailto:john.sundb...@kineticdata.com>> wrote:
> **
> Just wondering — say you wrote your own console … how can you not
> “tap” the license unless you need it?
> Is this reserved only for the BMC provided consoles?
>
>
> -John
>
>
>
>
> On Mon, Nov 2, 2015 at 11:34 AM, LJ LongWing
> <lj.longw...@gmail.com<mailto:lj.longw...@gmail.com>> wrote:
> **
> Ryan,
> As I understand it, this isn't a 'flaw' that needs to be 'backported'...but
> instead, a change in direction from their long standing stated policies.
>
> As I understand it, and somewhat agree with...the reason that a Float Write is
> accompanied by doing a query, instead of at attempt to write, is quite simple.
> If a user is doing a query for some data, they are more than likely trying to
> find something that they need to modify, and as such, will need a write
> license in the near future. Along those lines, if they didn't request a write
> till they were actually trying to write, it might be frustrating to the user
> experience.
>
> Now...with that said...when the policy was put in place (as I understand
> it...almost from the beginning...certainly not recent)...there was no concept
> of an 'overview console' that allowed people to query every form in the system
> for relevant information and consolidating it into a console/dashboard type of
> functionality....when this was done, and applied the old methodology of 'a
> query likely means a coming modify', then as you know, this then causes
> massive quantities of float licenses to be unnecessarily consumed. When it
> was pointed out to BMC that this was occurring, and how 'unfair' it was, BMC
> apparently decided to change it so that the overview console was allowed to do
> its queries without incurring a penalty on the cost of the system by
> allocating licenses to everyone in the console.
>
> So....while it was a design choice with unintended financial consequences...it
> was not a flaw, or a bug....and in order to avoid this feature, you need to be
> on the version of the tool that changes the direction and avoids this one
> scenario....
>
> I'm not a major fan of the 'it's a feature, not a bug' discussion...but in
> this case, I agree with BMC's logic that it wasn't a bug....I don't
> fundamentally agree with the idea of allocating float write on query...but
> it's not my tool, and I don't make the rules :)
>
> On Mon, Nov 2, 2015 at 9:15 AM, Ryan Nicosia
> <ryan.nicosia....@socom.mil<mailto:ryan.nicosia....@socom.mil>> wrote:
> We are on 7.6.04 with Mid Tier 8.1. So, based on Doug and Misi's response it
> sounds like it is fixed in newer releases (we are moving to 9.x this coming
> spring).
>
> That begs a follow up question or 2.
>
> If this is indeed a flaw with 7.6.04, one could argue we have been overpaying
> for licenses since 2012. Unfortunately, since the user.log logs these
> interactions and we are using the RRR license tool to determine how many
> licenses we need, it appears there is no easy way to figure out how many
> actual write licenses we need and should assign.
>
> 1. Does anybody have any recommendations on how to address with BMC when with
> our annual license renewals?
>
> 2. We have queried SQL with the 1900+ write license consumers and determined
> that 500 of them have never updated a ticket or entered a work log entry in a
> ticket. Would setting them to Incident "viewer" be a good work around?
>
> 3. Is what has been fixed in 8.x relative to the "flaw" something we can apply
> to our 7.6.04 environment?
>
> Thanks AR listers!!
>
> Ryan
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at
> www.arslist.org<http://www.arslist.org>
> "Where the Answers Are, and have been for 20 years"
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
>
>
> --
>
> John Sundberg
> Kinetic Data, Inc.
> "Your business. Your process."
>
> 651-556-0930<tel:651-556-0930> I
> john.sundb...@kineticdata.com<mailto:john.sundb...@kineticdata.com>
> www.kineticdata.com<http://www.kineticdata.com/> I
> community.kineticdata.com<http://community.kineticdata.com/>
>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
