Doug,
Thank you for the clarification.
Best Regards - Misi, RRR AB, http://rrr.se
> Misi,
>
> This is an application topic not a server topic.
>
> As has been noted, there is no error in or change to the licensing. The flaw
> is that we wanted to show a consolidated list and it had the side effect of
> grabbing licenses from every application. BMC decided that this was not
> behavior that we desired, but we did want to have a consolidated list. So, we
> adjusted how the application did work so that the console itself showing the
> list would not grab a token.
>
> The server version does not matter. It is the application that counts.
>
> As for the plugin you mention, you should find that it is gone. We changed
> the entire strategy of how the overview console works for performance and
> scale and customization reasons and have eliminated the use of a plugin to get
> the list of items to show in the overview console.
>
> Doug
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: Wednesday, November 04, 2015 6:58 AM
> To: [email protected]
> Subject: Re: Serious flaw in BMC Remedy Licensing
>
> 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:[email protected]] On Behalf Of LJ LongWing
>> Sent: Monday, November 02, 2015 10:21 AM
>> To: [email protected]
>> 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
>> <[email protected]<mailto:[email protected]>> 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
>> <[email protected]<mailto:[email protected]>> 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
>> <[email protected]<mailto:[email protected]>> 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
>> [email protected]<mailto:[email protected]>
>> 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"
>
> _______________________________________________________________________________
> 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"
