Conference noted::pwv50ift

    .0> The customer had the unsupported FPA kit on the NT4.0 and was working -
    .0> he had a WNT04.01 license.  He then "upgraded" to PW32 bits.  He
    .0> successfully obtains (now verifies) a FPA (and WINAT07.00) license from
    .0> the license server, but he can't connect.  
    
    Well, this might be an easy one ... the WINAT07.00 license is _NOT_ an
    FPA license - it's a CNS license (by old terms), the license to use the
    PW32 client software. (the "AT" in WINAT is applications and transports) 
    
    The current FPA license is still PWLMXXXFP05.00 (or any other CC
    license which (implicitly) contains a FP05.00 license).
    
    .0> So how does the license registrar cache work and what info does it
    .0> store/check to determine if a client is in it's cache?  
    
    The LicReg simply knows the client by the name provided to it by the
    file server and the time the client's license was first validated. When
    a request is received by the LicReg, the LicReg first scans its cache
    to see if the client is in the cache and if not, the LicReg procedes to
    ping the client to validate the client's license. After the client's
    license is validated, the client is inserted into the cache 
    
    .0> Is there some way for the client to be denied access due to a license
    .0> issue even if it's in the cache (ie, issue between lmsrv and
    .0> license_r?)?
    
    If the client is put into the cache, its license has been validated as
    being sufficient for accessing the file server.  There are only two
    situations I can think of which may cause a client to be denied access
    after it's been inserted into the cache:
    
      1) if the LMsrv cannot communicate with the LicReg - then all
    	 requests by the file server to the LicReg to validate licenses 
    	 are rejected.
    
      2) if Client1's license (which has already been validated and Client1
         was inserted into the LicReg's cache) was copied to Client2 and used 
         by Client2 to access the same file server, and Client1 could not
         be contacted by the LicReg - in this case Client2 would be granted
         access (and put into the cache) and Client1's entry in the cache 
         would be marked as invalid.  If Client1 subsequently attempted to 
         connect to the file server, the above scenario should just cause the 
         LicReg to not find an entry in the cache for Client1 and therefore
         cause the LicReg to ping Client1 looking for a valid license.
    
    .0> Is there a way to flush/list the cache contents?  I know I've seen
    .0> (someplace) that there's a way to disable it, but can't find it - could
    .0> someone enlighten me?  Also, can the flush interval be changed (or just
    .0> disabled)?
    
    The contents of the cache cannot be flushed or listed - the cache can
    only be disabled:
    
    	$ define/system PWRK$LrNoCacheCheck 1
    
    .0> What kinds of anomolies can we expect when a client is using one set of
    .0> license bits/license types, gets in the license_r cache, and w/i 24
    .0> hours now has different license bits/types?  Is PWRK$LICENSE_R built to
    .0> handle these situations?
    
    The LicReg doesn't do anything special to handle the circumstance
    described. The LicReg cache entry is good for 24 hours.  Connects to
    the associated file server within the 24 hour period will be honored
    and no ping will be done.  When the cache entry becomes invalid after
    24 hours, the next connect attempt made by the client will cause the 
    LicReg to ping the client looking for a valid license.  Therefore,
    today my client may access a file server using a PWLMDOSCC06.00 license
    and tomorrow it might use a PWLMXXXFP05.00 license.  Both licenses are
    good at the time of validation - that's all that matters.
    
    .0> On an aside, I worked with a customer who was getting connected to a
    .0> v5.0E server and the WNT 3.51 client was NOT licensed!  How?  The guy
    .0> had a dual-boot Win95/WinNT client.  He had, at 9am that morning,
    .0> booted Win95, verified his dos CC06.00 license, and connected.  Later
    .0> in the day he booted NT, tried to obtain an FPA license but failed
    .0> because there were none (it also Released his DOS CCS license) yet he
    .0> was still able to connect to the server.  No server based licenses.  My
    .0> assumption was that since the computername was the same for both his 95
    .0> and WNT configs, the license_r 24 hour cache was letting him connect. 
    .0> Correct or not?
    
    I can't say for sure, but your hypothesis would be my guess as well.
    
    Hope this helps,
    \steve

    Paul,
    
    I have succesfully reproduced this here. Actually used it as a
    work-around for customers once or twice.
    
    Mike

> We noticed that the pw32 event log isn't showing the "Presenting
> license...." message when he tries to connect.  (BTW, whomever had the
> foresight to post these "Presenting license" messages should be given a
> raise!).

	Tell that to my boss:  Vivianne Majewski (JAMIN::Majewski)