Configuring Eye-Fi Manager as a Service for Windows Home Server

After configuring my Eye-Fi Manager appliction on the Windows Home Server, I quickly noticed a problem. The application is executed by the currently logged on user and not as a service. Because I am connected to the Windows Home Server via Remote Desktop I logoff the server once I’m finished and the application shuts down.

Solving the problem requires it to be running as a service. I looked at the forums for Eye-Fi and their website and there is a thread on the forum for exactly the same thing – Configuring Eye-Fi Manager as a service, however it doesn’t actually go into any details so I had to figure it out for myself.

The Service Command (sc.exe) application makes this real easy for me to do. The following command should as done the trick.

sc create EyeFiManager DisplayName= “Eye-Fi Manager” start= auto binPath= “C:Program FilesEye-FiEye-Fi Manager.exe”

Unfortunately when I tried to start the service, Process Explorer showed me the Eye-Fi Manager.exe application as running however after a few seconds it terminated and the Services MMC console gave the error that the application didn’t respond in a timely fashion, so the application is obviously not designed to be a service, I therefore needed a middle man.

Microsoft produced a utility for NT4 called srvany.exe which still works in Windows versions today. The premise is very simple. srvany.exe is the service executable and you provide your executable as a parameter for srvany. The result is that srvany handles the service and responds to Windows as required.

I’ve put a copy of the executable srvany.exe on my Windows Live SkyDrive for you to download for your own uses. In my example, I placed the executable in the System32 directory so that I can call it without declaring the path to the application and without having to add custom strings to the Path environment variable.

To this end, the command becomes the following:

sc create EyeFiManager DisplayName= “Eye-Fi Manager”  start= auto binPath= “C:WINDOWSSystem32srvany.exe” 

Once this is done, you need to instruct srvany the name of the executable you want it to handle. This is done easily using the reg command line tool as follows:

reg add HKLMSYSTEMCurrentControlSetServicesEyeFiManagerParameters /v Application /t REG_SZ /d "C:Program FilesEye-FiEye-Fi Manager.exe"

Starting the EyeFiManager service I created that launches srvany.exe will now start the Eyei-Fi Manager.exe application and it will run as required, with the exception that none of the user interaction such as thumbnail previews of the uploading pictures can be seen as it’s a background service.

I proceeded to test it and unfortunately I noticed a problem. Although the application was running it wasn’t processing any uploads. I immeadiatly assumed the problem was the permissions relat

reg add HKLMSYSTEMCurrentControlSetServicesEyeFiManagerParameters /v Application /t REG_SZ /d "C:Program FilesEye-FiEye-Fi Manager.exe"

ing to the default account used by servcies which is the System account. I decided to change thhe service to use the NetworkService account as this would allow it access to the network.

The following reg command performs this for me:

reg add HKLMSYSTEMCurrentControlSetServicesEyeFiManager /v ObjectName /t REG_SZ /d "NT AUTHORITYNetworkService"

After restarting the service, I still couldn’t upload the photos. I assumed it was NTFS permissions now, so I added the NetworkService account to the RW_7 group on the Home Server, which is the group created by Windows Home Server for permitting Read and Write access to the Public folder*.

* The reason I upload to the Public folder is that I like to rename, tag and adjust all my pictures before allowing them into the Photos shared folder.

Unfortunately this still didn’t solve the problem. Using Process Explorer and comparing the results (specifically the TCP/IP Stack) of the Eye-Fi Manager.exe process when it was running as a local user and the NetworkService account showed that the NetworkService service version didn’t open up the required TCP Listening ports.

At this point, I created a service account called svcEyeFi and used that account to launch the service, however this has the same results as the NetworkService account even after adding the account to the Local Administrators group.

I have now resorted to the the idea and am running the account using the Local Administrator account which is the account you use to login to the Windows Home Server Console for management purposes. It’s not ideal for security and principal of least privilege, however it works so that’s a plus I guess.

I decided that I wanted my service to look a bit less like a virus or trojan service and more genuine, so I deleted the service using the sc delete EyeFiManager command and then re-created the service using these commands as follows:

sc create EyeFiManager DisplayName= "Eye-Fi Manager" type= own start= auto depend= Netman binPath= "C:WINDOWSSystem32srvany.exe" obj= .Administrator cEyeFi password= [password]

reg add HKLMSYSTEMCurrentControlSetServicesEyeFiManagerParameters /v Application /t REG_SZ /d "C:Program FilesEye-FiEye-Fi Manager.exe"

reg add HKLMSYSTEMCurrentControlSetServicesEyeFiManager /v Description /t REG_SZ /d "Starts the Eye-Fi Manager application as at automatic system service allowing it to run without a user logged in."

So what does all of this do exactly?

Well the first line creates the service, marks it as Automatic start-up type, sets it to start using the local Administrator account and lastly adds the Network Connections service as a dependency. The addition of the dependency means that this service cannot start until the network connection is up and available.

The second command adds the parameter to the srvany application to start Eye-Fi Manager.

The last commands sets a description on the service so that anyone looking at the Services MMC will see what the service is doing.

For a bonus point, you can configure the recovery options so that if for any reason the service fails it will automatically restart the application.

If anyone trying to configure this runs into problems, email me and I’ll be sure to help you out.


Richard works as a Cloud Consultant for Fordway Solution where his primary focus is to help customers understand, adopt and develop with Microsoft Azure, Office 365 and System Center. Richard Green is an IT Pro with over 15 years' of experience in all things Microsoft including System Center and Office 365. He has previously worked as a System Center consultant and as an internal solutions architect across many verticals. Outside of work, he loves motorbikes and is part of the orange army, marshaling for NGRRC, British Superbikes and MotoGP. He is also an Assistant Cub Scout Leader.