IMatch 5.8.4 and IMatch Anywhere 2017.1.8 released

[hro]

I just updated both versions, no problems installing them as usual 

However, when I started IMA the service could no longer find my photos which are stored on a NAS. When I ran IMatch there were no problems. The database has a relocate definition that points to the NAS.

After further research I identified that the IMA update appears to reset the service logon account to the default "Local System Account', removing any user defined account setting. After I added back my user defined account (which is required for accessing the NAS) IMA could again access my photos.

Is it possible to change this behavior so that user defined account settings are retained during an update?

Thanks. Hartmut

[Mario]

This is a Windows problem. Updating / Re-installing a service resets it to the default user. There is no way for an installer to retrieve the user name and password (for good reasons) and to restore them after updating the service. There may be a way to prompt the user during installation for a user name and password. But, frankly, Windows Installer is one of the most complicated pieces of software ever written and a simple task like creating a user interface to prompt a user for a user name and password may require a week of training, a purpose-written external DLL and whatnot. And then it runs on 50% of all systems but fails on the rest. Sorry, nope.

This behavior is documented in the IMatch Anywhere documentation and you should get a warning after installing a new version when you did change the default user account previously.

[hro]

Understand. I am happy if this is documented. I must admit I haven't spotted it in the documentation, will re-read.
However, I don't think I got a warning when I updated, which would be sufficient as well.

[Mario]

It is documented:



and IMWS will display a system warning when it cannot access your drives anymore.

Which reminds me: IMatch WebService Controller offers you to run the service under a specific user name and password. You don't need to configure the service manually. Why don't you use that instead? This avoids this problem completely.

[hro]

Thanks Mario.  I didn't doubt that it was in the documentaion, just didn't see it.  I'll remember for the next update.

[hro]

"Which reminds me: IMatch WebService Controller offers you to run the service under a specific user name and password. You don't need to configure the service manually. Why don't you use that instead? This avoids this problem completely."

You are right. I'll try that out as well. Too much to absorb. At the moment I am struggling with getting a reverse  proxy server on Apache to work. But this will be another post.   

[Mario]

Go to Configure > Advanced Options:



This tells IMatch Anywhere to run the service under the given user account. No need to manually configure the service user account.
See the documentation for details about this setting and all the others.

[hro]

I have now added the service user account in the Advanced Options, restarted the service and it works perfectly.

However, whenever I now run the webservice controller app, it pops up the following dialog every time. This doesn't seem correct as the service was re-started and is running under the user name I defined.

[Mario]

This message is only displayed when the controller actually had to change the user name (it compares the name the service runs under with the name configured here). Either the controller is unable to change the service user name or the test is messed up.

Please attach your service controller log file (IMATCH_WSC_LOG.txt from your TEMP folder).

[hro]

Here is the log file as requested.

[Mario]

The log file only says:

Service user account updated successfully.

which is good. It means that the service account was updated. I don't know why this does not "stick" on your system.
Maybe when you switch to debug logging (Advanced Options) in the Controller we get more info in the log file...

[hro]

OK, here is another log file with verbose debug logging enabled.

[hro]

Not sure which is the correct log file. Here is the IMATCH_WSC_LOG as well.

[Mario]

The service log shows "Service runnung under user account 'Administrator'". And the controller reports a successful change of the user account.

Do you also see this message when you configure the service manually to run under the 'Administrator' account?

[hro]

I just re-configured the service to manually again and the message does not come up. Log files attached if they can tell you anything.

Not sure if this makes a difference, but I noticed that the user credentials are getting "somewhat transformed"  by the web service, i.e. user name entered in the web service is "PHOENIX\administrator" and it shows up as ".\administrator" in the logon properties panel of the service. When I configured manually I entered the full computername\username option.

[Mario]

.\username is the recommended shortcut for LOCAL-MACHINE\username. The function the controller uses to configure the service demands this. But it's a hint. Maybe the string compare IMWS does fails because of that. I did not notice this during my tests, through.

I'll look into this for one of the next releases.

Question:

In the controller, do you specify the user as:

UserName
.\UserName
MACHINE_NAME\UserName
DOMAIN_NAME\UserName

I've had a look at the code and it looks correct.
If you don't specify a machine or domain name, the controller uses .\username, which mean "local machine".
It also does the comparison correctly as far as I can see.
I've added a number of extra log file entries so we get more info in the next release. Maybe this sheds some light on this.