INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Windows => Topic started by: slerch666 on June 10, 2016, 08:25:20 am
-
I convinced my company to purchase licenses for MC (ver 18) because legal concerns over having VLC on a bunch of machines many moons ago, and for the most part, everything was smooth. Recently we've begun seeing some issues where the automatic process for consuming a license wasn't working, and I'm struggling to figure out where to take this next. I've gotten a lot of things to try from Matt via email, none of which seem to work, so I figured I'd post here, just in case someone has some further insight.
When the process works, during system imaging (using MDT 2013 Update 2 for system deployment) MC gets installed, and reads a license key from a network share, marks the license consumed, and MC reports as properly licensed. Mainly Windows 7 64 bit deployments, with a very, very small hand full of Windows 10 installations.
Here is the automated installation script, using local administrator for installation during imaging, and this is BEFORE domain join. I've removed and renamed anything that could potentially name the company (I'm not authorized to speak for the company around endorsements, blah blah blah).
@ECHO OFF
TITLE Mediaplayer
MediaPlayer180188.exe /silent
::BEGIN THE LICENSE PROCESS
::LOG INTO LicenseShare
NET USE \\SERVER NAME HERE\SHARE NAME HERE /USER:USERNAME HERE password here
::RUN LICENSE PROCESS
PUSHD "C:\Program Files (x86)\J River\Media Center 18"
PackageInstaller.exe /BlockLicense "NET USE \\SERVER NAME HERE\SHARE NAME HERE\LicenseFileNameHere.txt" "Silent=1" "Email=email address here" "Name=%SERIALNUMBER%" "Company=Company Name Here"
95% of the time, this works perfectly.
Here is what it writes to the file, and you can see the time stamp, company, etc is written - it just doesn't license properly on the local machine:
25-digit-key-here Redeemed: 2016-06-06T07:50:23; Name: SERIALNUMBER HERE; Email: email@email.com; Company: COMPANY
The other 5% of the time, it seems that the problem occurs on a re-image of a machine (fresh installs are almost ALWAYS licensed). On a reimage of a machine, or a re-license of a MC install, the license process reads the serial number of the system. If that SN already has a license, the license process reads the license key for that installation, updates the license file information, and registers. On machines where this fails during imaging, it fails when we run a re-license process using our configuration management software for deployments after the image deployment is completed. If I manually grab the license key, jump out to the license restoral page and go through the process, then open the file on the impacted machine, it works every time.
One thing to note is that this is generally occurring on machines from other regions. The network share is on the US east coast. Share is on a Windows Server 2012 R2 machine, from which we share all sorts of other files.
Failures happen from our US western plants, we've also had failures from our Asia Pacific region, and EU. They all read the same license file from the US east coast region, and every failure still has the license file read/written to.
Things I've investigated and ruled out:
- Share not available - I've paused the task sequence in imaging, popped open a CMD prompt, done Net Use to list active connections and the share is listed as expected
- Another reason I know it is reading the file - I have Notepad++ open, with the license file opened. It alerts me the file was updated, I refresh, look up the serial number for the machine and it clearly shows it has written to the file and read the license
- Network connectivity remains during the entire process
- License file share is open for the user account to read/write/modify - like I said, this works 95% of the time with this user account and this same process
- Machine is not domain joined during imaging - even trying once joined to domain fails
- Group Policy is NOT the issue - because it's not domain joined during this process, GP is NOT being applied
- Administrator elevation issue - every single process run during imaging is done with the LOCAL admin account, the built in Windows admin account. Privilege elevation is not a concern. AND it works 95% of the time during the same process
- Manually running the license process on the same machine, at any point in the future, continues to fail.
PackageInstaller.exe /BlockLicense "NET USE \\SERVER NAME HERE\SHARE NAME HERE\LicenseFileNameHere.txt" "Silent=1" "Email=email address here" "Name=%SERIALNUMBER%" "Company=Company Name Here" - Running the license process with a different license key, consumed by another machine, using the serial number of the working machine, continues to fail, so it's not an issue with the license key
- Virus Scan is completely ruled out. Where the MC installation occurs, our virus scanning solution is NOT installed, nor is our encryption solution
So what I am wondering is, for MC gurus and Windows client/server gurus, anything else you can think would potentially be worth investigating? I am getting the stink eye (and stink emails) from our help desk folks since my team is the only one with access to the license file.
Anything you can think of that might be worth trying I'm pretty much game for. My team is tired of getting help desk tickets to get license keys for these, and the help desk guys already hate my team enough as it is. lol
Thanks in advance.
-
You said that region might be a factor. That suggests time as a factor. Wrong date set, for example.
Having the license file open in notepad at the same time seems a little risky.
Antivirus programs are always my first guess in these kinds of cases.
-
Thanks Jim.
100% not antivirus related (or I can't see how it could be), because at this point in the process, our corporate AV solution isn't even installed, and Windows Defender not configured. Imaging process is reliable and the results are consistent for all but this small hand full of machines.
I was thinking date/time may be an issue, but again, at this point in the process, with the exception of MAYBE 5% of the machines, it is successful. And I think 5% is high, as we get maybe 2 calls a week now (up from a high of 10-15 calls per week when the share location was unreliable). In checking date/time on a broken machine, it matched the date/time in the expected range from UTC. I assume, given the success, that the machines don't need to match the Eastern time zone, just match via UTC/GMT equivalent?
With Notepad++, it's pretty robust in the way it works. As long as I don't press save after the file is changed, it won't impact the file. And I've only done this when imaging a machine known to fail to ensure it was actually accessing the file, which it was. Even on a re-re-image of the same machine, w/o the license file open, you can see that it's read and written to the file, it just doesn't register on the local machine for some reason.
-
Are you able to put a sleep before and after the licensing?
I know you've thought of all these things ...
-
And did you look for licensing problems in this thread?
http://yabb.jriver.com/interact/index.php?topic=24031.0
and in the antivirus thread (linked from the first post of that thread)?
-
Thanks Jim.
Will dig back through those threads on Monday when I get back into work. For now though.... WEEKEND!
-
Hey Jim.
I dug through that thread for licensing issues. Nothing really seems to be relevant in this case.
Not sure what else to try here. I may just tell the help desk guys it's as reliable as we can make it and call it a day. 1-2 a weeks isn't horrible, but not perfect, obviously.
-
One thing you could try on one of the machines that fails to update with the script, try running the script without the "Silent=1" option. Then it might show a message box with a useful error message. With Silent enabled, the error message is thrown away. If it fails and still doesn't show a message box, the problem must be a little deeper.
Is there any commonality to the failure cases? Do those emails have non-English characters in them for example? Or are there hidden spaces or tab characters in the block license file, like before or after an email address or registration code or serial number?
The block licensing program depends on the block license file being in UTF8 encoding with BOM (byte order mark). If it was saved with an editor to a different format, that could cause problems for non-English characters in the file.
On a machine that's failing, try copying the block license file to it's own hard drive and modify the script to utilize that file instead of the network shared one. Just to eliminate networking weirdness from the equation.
After a failure on a re-imaged machine, if you use regedit to examine it's registry, do you see any entry named "18" under this folder?
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\JRiver\BuyButton\2.0\JRiver, Inc.\Media Center
Could there be any issues with a few random machines not having permission to write to the Local Machine registry from that script?
If you contact me following a failure (johnt at jriver dot com), I could check our server logs. Just provide the approximate time/date and the info about the particular license (email, serialno, etc.).
- John
JRiver
-
Hey John!
I will take a look at the encoding of the file, but pretty sure it's UTF8. Serial numbers being read in are non-unicode alphanumeric, even on our Japanese/Chinese PCs. Since the current crop of failures seem to be on our west coast (US) facilities, I don't think that should be the issue here either. But I will double check it all.
The email address we use is the same under all registrations (user@company.com - but obviously an actual email address). The email address doesn't change for any region.
I will try the non-silent script again when I find a machine someone will let me poke around. Usually I get access to them for an hour at most before people get tired of not having their PC ready. You know how it goes.
I will also check the registry. If memory serves, the structure isn't there after the process, BUT I didn't specifically watch it, so I could be mistaken here. Again, once I get one that fails, I will check this out.
If that all still fails, I'll get you the information on when the failure occurred and other pertinent information.
-
Sounds good. Just let me know.