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"
