Registration via internet of newly installed software (on each machine)

[Arthur]

BUT THE QUESTION IS WHERE? HKCU was what I suggested as a possibility in my previous post, because Arthur said that user permissions would not allow the data to be stored in HKLM or in the all users directory / program data directory

To keep things as simple as possible I think you are going to have to assume that the user doing the installation of Task Magic has the relevant permissions to be able to write to the registry (HKLM) or the install folder (%ProgramFiles%\TaskMagic). If they don't, then they shouldn't be installing software.

 

On Vista & 7, you also want to avoid getting into a situation where registry keys and files are being silently redirected to other locations due to UAC virtualization, which happens when a standard user tries to save to protected areas of the file-system and registry. The article below has some really good suggestions on what to do on those OSs.

 

http://windowsteamblog.com/blogs/developers/archive/2009/08/04/user-account-control-data-redirection.aspx

Edited April 5, 2010 by Arthur

[mlapworth]

To keep things as simple as possible I think you are going to have to assume that the user doing the installation of Task Magic has the relevant permissions to be able to write to the registry (HKLM) or the install folder (%ProgramFiles%\TaskMagic). If they don't, then they shouldn't be installing software.

I agree, but this isn't about when the software is installed. This would happen when either of the TaskMagic programs is run, so that a local copy of the registration data is kept.

 

I know that if I am creating or setting registry keys during installation, these should be made in HKLM, but I'm attempting to use a method whereby registration is separate from installation (in order to avoid custom actions). Registration is required if no registration data is found - but once the person installing the software has registered it (following installation), the registration data will be created on the network drive and no other users / computers connected to the internet will need to register.

 

So the person installing the software can specify a network path to store the registration data. (no need to store it in HKLM)

The ONLY time the locally stored data would be needed is if a computer that has had the software installed with a modified config file (ie. telling the computer to look on the network for the reg data) is disconnected from the network, and the user tries to access TaskMagic.

[mlapworth]

I also meant to add that the registration info would be kept independently of the exe files. So if you uninstalled / reinstalled / updated the software, there would be no need to register again.

[p858snake]

The type of system I would like is where there is a licensing app/server set up where the license keys and such put into then when the application is installed it is told there is a local licensing server to connect to, And if that server can't be found or not told to look for it during install it can default to outside registering.

 

This way you can do things like have 20 concurrent user licenses and install it on all the systems but only 20 users can open and run it.

 

And some diagram fun for those that like that stuff:

[Kipling]

...

c) each time the programs are run, they look for the registration info in the specified location (if no location specified then they'd look in the programdata folder and/or the HKLM section of the registry).

d) if there is a specified path in step c above, and this path is available, and regsitration data is present at that location, copy the data from there to the local machine (BUT THE QUESTION IS WHERE? HKCU was what I suggested as a possibility in my previus post, because Arthur said that user permissions would not allow the data to be stored in HKLM or in the all users directory / program data directory).

...

This is the bit thats causing a hiccup, you want the program to copy registration data from the network to the local drive so that if the machine is taken off the network it will still find its licence; but you want that to happen on every run, which implies doing it under standard user permissions. Like Arthur says, your choices of locations are limited there.

 

Also what’s to stop someone with a 10 licence version, installing it on a hundred pc’s and then deleting the registration data off the server. All 100 machines will happily look to their local licence copy and work without blinking.

 

 

 

 

How about this (based on sibelius’ licensing model).

 

• You supply only one CD/download.
  
• The CD has the user program and a licence server program.
  
• If the purchaser only bought one or two licences then they install them by hand and register with you over the internet as they currently do.
  
• If they bought say 10 licences, they:
  
  • install the licence server on a server (or pc that is always on)
    
  • start the licence server and “install” a key/file/code emailed from you which dictates how many concurrent users can run the software.
    
  • Modify a file in the install pack (you suggested tm.config I think) to point to the licence-servers IP address/name.
    
  • Push out the (now modified) user program over the network to all clients or run it from a network share etc.

  [*]When a user launches the program it queries the licence-server so ask permission to run (the licence server keeps a count of how many users are currently using the software).

 

For home users there’s no simple solution. There will have to be an element of trust, you could use the same key/file/code that the licence server uses and have your client program look locally if the licence-server can’t be found; if the key/file/code has been installed locally then allow it to run. Not much protection but it could have the school details embed within the key so al least there’ll be a splash screen.

 

 

Advantages

Good on the network because it can be installed everywhere.

No chance of accidentally going over licence because the licence-server will prevent that.

Allows you to sell more licensing options, e.g. 100 user, 200 user, 300 user etc.

 

Disadvantages.

More involved changes to your current code base.

A licence server to write/test.

Doesn’t address home users needs too well.

[Arthur]

a) by default, require registration on each machine over t'internet.

Would it be possible to elaborate on this part a little? When a customer buys Task Magic, would they be e-mailed a username and password to login to your website and download the single file containing their registration details? What would prevent someone from buying a single user license, specifying a local path to the registration data in the tm.config and then repeating the process on other computers?

 

Edit. Didn't see Kipling's post above mine.

[mlapworth]

Thanks Kipling and Arthur. You both come up with the same disadvantage in terms of security. I guess it's useful to see this in the context of the current version which doesn't require registration at all.

 

I'm actually not trying to find ways of controlling the number of users using this reg data. I'm back to trusting in the honesty of the poeple in the school really...

 

The school is provided with a registration key along with their CD. When they run the software and get to the registration screen - step f in my scenario a few posts ago, they will need to key in the registration key. This will then download a file from the taskmagic website containing the licence details for the school.

 

When the program is run subsequently the school's name and licence type will appear on the splash sceen when TaskMagic opens. A pop-up will also appear at random intervals (hopefully not enough to be too much of a nuisance, every nth time a game screen is opened for example) saying that the software is licensed for use on 1 / 10 / all machines in the school (the name of the school will appear here too), and encouraging the reader to contact us if they suspect that the software is being used illegally...

 

So if you pass on your registration key to another school, the splash / popup screens will hopefully be enough to discourage the other school from using the software.

 

Our single user / 10 user licences are not concurrent users, but machines on which the software can be accessed without being in breach of the agreement. There's nothing physical to prevent this.

Edited April 5, 2010 by mlapworth
changed screen to school in penultimate paragraph

[featured_spectre]

I still think a hidden ini file might be more beneficial, doesn't mess with registry, and backups can be kept.

 

But that's just me and how I prefer it.

[Kipling]

I'm actually not trying to find ways of controlling the number of users using this reg data. I'm back to trusting in the honesty of the poeple in the school really...

So it’s more to customise the software a little with a splash screen rather than any form of forced licence compliance.

 

In that case I think the best solution is the one Arthur suggested a few posts back.

What about something like this?

 

1) An MSI that performs a per machine installation with files stored uncompressed externally (as described above).

2) The Task Magic MSI copies a license file (called something obvious like "tm.license" or "tm.lic") to the install folder during installation. This would be located in the same folder as the MSI. In order to do this as part of the installation you would need to include some sort of dummy license file which will have to be overwritten with the real license file BEFORE Task Magic is deployed to computers. When Task Magic runs, it verifies the license file and works as normal if everything checks out. If there is a problem or it can't find this file, either...

 

 

To summarise it:

You supply your program in an uncompressed format with an msi file and have a dummy licence file included within the structure.

 

The network admin then has a few options.

a) Contact you and get the correct licence file emailed across. Replace the dummy file with the new one and push the whole lot out over the network.

or

b) hand install the software on one PC using your current online registration system. Once completed, copy the newly downloaded licence file from that PC and overwrite the dummy file on the server; then push the whole lot out over the network.

 

 

It’s simple, it’s guaranteed to work, it doesn’t run into any user permission problems and it allows users to continue using the software when not connected to the network.

If the software gets upgraded all the admin has to do is make sure the real licence file is copied over the dummy one again and let it roll out to clients.

[mlapworth]

Thanks for all your help. I've gone with what was suggested by Kipling / Arthur. A dummy licence file is included along with the msi, unpackaged. The person installing to the network can register on one machine, then copy the new licence file to the installer before rolling out across the network.

[Arthur]

That's great news, Martin. You will have certainly pleased a lot of IT tech's/NMs.

 

Thanks also for taking our feedback on board. Many educational software developers wouldn't even bother to do what you have done.

[mlapworth]

OK, here I am 18 months on.

 

I used the model as suggested by several people on here, and it worked a treat. In the last couple of months, however, there have been several reports of the process not working as it should. What's happening is that, after registering on one machine and copying the modified file into the installation directory, when this is installed to the network, the modified file isn't installed (ie. it isn't copied across). I haven't changed anything, as far as I can see, so I'm completely puzzled as to why this should be happening now, when it worked fine for the first year or so (with ZERO reports of it not copying the file across).

 

Any ideas?

[pete]

OK, here I am 18 months on.

 

I used the model as suggested by several people on here, and it worked a treat. In the last couple of months, however, there have been several reports of the process not working as it should. What's happening is that, after registering on one machine and copying the modified file into the installation directory, when this is installed to the network, the modified file isn't installed (ie. it isn't copied across). I haven't changed anything, as far as I can see, so I'm completely puzzled as to why this should be happening now, when it worked fine for the first year or so (with ZERO reports of it not copying the file across).

 

Any ideas?

 

Have you checked they're not numpties?

 

Ask them to provide the .msi install log. i.e

msiexec /i \\server\share\tm2\tm2.msi /L c:\tmlogfile.log 

 

and look for obvious problems.

 

Try to replicate the issue.

[Arthur]

What's happening is that, after registering on one machine and copying the modified file into the installation directory, when this is installed to the network, the modified file isn't installed (i.e. it isn't copied across).

Is this only happening when they perform a network install? If they double-click the MSI and install it manually (after they have copied the license file to the install folder) does it work?

[mlapworth]

Thanks for your reply Pete. That's what I thought at first, but there have been several similar reports now over the last month or two. I haven't asked them to provide the log file. I'll maybe do that, and try to replicate it on my computers here.

[mlapworth]

Is this only happening when they perform a network install? If they double-click the MSI and install it manually (after they have copied the license file to the install folder) does it work?

I'm not sure. I guess a good starting point for me would be to see if it installs on one of my computers if I replace the file. Thanks for your reply.

[mlapworth]

Is this only happening when they perform a network install? If they double-click the MSI and install it manually (after they have copied the license file to the install folder) does it work?

 

I've just tried installing it on my computer after copying the modified file to the installation folder first. It worked fine. Is there any reason why it wouldn't work across a network if it works on one computer?

BTW the computer I just tried it on was XP. Also, the number of bytes in the modified file is 3 more than the original. Would this make a difference?

[3s-gtech]

I recently installed it on some Windows 7 x64 machines and a Windows XP machine via .msi unattended, it rolled the license file out fine that's in the deployment share. Wouldn't register through the proxy for love nor money, but just took my laptop home to do that.

[mlapworth]

I recently installed it on some Windows 7 x64 machines and a Windows XP machine via .msi unattended, it rolled the license file out fine that's in the deployment share. Wouldn't register through the proxy for love nor money, but just took my laptop home to do that.

 

Thanks for your reply. A couple of schools have contacted me to say they couldn't register as they were behind a proxy server. I just emailed them a copy of the licence file.

 

The issue is not with sending out the licence file that's already in the installation folder. This always installs no problem. But if you modify it (or rather, replace this one with a modified one) some people are saying it isn't copied acroos by the installer...

[featured_spectre]

Is it just network installs that are having the issue? (sorry if I missed it, got a 2 year old running around, on the phone, and writing a document up as well! lol)

[mlapworth]

Is it just network installs that are having the issue? (sorry if I missed it, got a 2 year old running around, on the phone, and writing a document up as well! lol)

I've tried installing it on my computer after copying the modified file to the installation folder first. It worked fine. Is there any reason why it wouldn't work across a network if it works on one computer?

BTW the computer I tried it on was XP. Also, the number of bytes in the modified file is 3 more than the original. Would this make a difference?

[Arthur]

if you modify it (or rather, replace this one with a modified one) some people are saying it isn't copied acroos by the installer...

Could it be related to the file versioning rules in Windows Installer?

 

Installing Non-Versioned Files

Installing non-versioned files with Windows Installer differs from legacy script-based installation tools. Most users expect the file with the most recent date and time to be installed. However, Windows Installer does not use this method to determine non-versioned file installation and instead uses a two-step procedure.

 

First, Windows Installer compares the file's unique hash value generated for its content with the MsiFileHash table in the .MSI. If the hash values match, then Windows Installer determines the files are the same and does not replace the file on the destination computer.

 

If the hash values differ, Windows Installer compares the date/time stamp of the file on the computer. If the file's modification date is newer than its creation date, Windows Installer determines the file contains user-modified content and does not replace the existing file. To override this behavior, use companion files.

 

By understanding how Windows Installer handles different file-replacement scenarios, you can create a package that installs in a predictable manner. For more information about file versioning rules, see the topic titled File Versioning Rules in the Windows Installer SDK. (Source)

 

Are the people having problems, installing TaskMagic on a computer which has previously had it installed? Which program are you using to create the MSI?

[mlapworth]

Are the people having problems, installing TaskMagic on a computer which has previously had it installed? Which program are you using to create the MSI?

 

I don't think it's related to versioning, as it's not to do with replacing existing files. (Which answers you 2nd question :0) This is for initial installs...

 

The problem might be to do with the program that creates the msi package (digitalweb installwizard) - but what confuses me is that it was working fine for over a year.

 

It's as if the installer doesn't recognize the modified file as being the same one listed in the msi - even though it has the same name, same attributes etc. The only difference is the extra 3 bytes - maybe I should make the original file 3 bytes longer and see if that fixes it.

[featured_spectre]

In terms of your registration, could you not set it up to point to a central location? For example N:\Program Name\reg.ini and then have it pull the registration information from there?

 

That way you bypass copying the registration around to different machines etc, and an MSI set up would be far simpler as you can predetermine where it installs from.

[mlapworth]

I don't think I'd do that within the msi. But it might be an idea to offer people the option to place the registration file somewhere else. I could do this via the configuration file, maybe.

Still don't know why it stopped working properly though...