1. Home
  2. Knowledge Base
  3. Softalk
  4. Workgroupshare
  5. I am running WorkgroupShare as a service under Vista using JET as the database and changes that I make in the administrator do not seem to take effect.

I am running WorkgroupShare as a service under Vista using JET as the database and changes that I make in the administrator do not seem to take effect.

Symptoms

Problems include:
1. If you add a user in the administrator, that user is not accessible from the drop down in client setup.
2. If you change permissions in the administrator, these are not reflected in Outlook.
3. If you add a public folder in the administrator and grant appropriate permissions, this is not accessible from the relevant users’ Outlook.

Cause

The problem occurs if the WorkgroupShare data folder is located under the c:program files folder and User Account Control has been turned on at some point.

User Account Control prevents users from writing to the c:Program Files folder. If a user tries to do this in Windows Explorer, they will be prompted for credentials. However if an application, such as the administrator, tries to do this, Vista will, for compatibility reasons, allow the write to take place, but will copy whatever has been written to the c:users{user}App DataLocalVirtualStoreProgram Files folder and will then make the change.

So effectively, Vista makes a copy of the WorkgroupShare database and starts writing to it in the new location. The service, however operates under the context of a different user and continues to access the original c:program files folder. As a result, the service and administrator end up using two different databases and any changes made by the administrator will not be picked up by the server.

Resolution

The resolution is to do the following:

1. Create a folder called c:Softalk.

2. Right click this folder and select Properties. Select the Security tab and press the Edit… button.

3. Select Users ({computername}Users} and in the bottom list tick the Modify tick box.

4. Under this folder, create a sub folder called SCS and under that folder create a sub folder called Data.

5. Press the Start button and into the search box type ‘cmd’. You will see the cmd application appear in the search results. Right click it and select “Run as Administrator” (you will need to provide your admin credentials). In the command window type ‘net stop workgroupshare’ followed by Enter. Also ensure that the WorkgroupShare administrator is closed.

6. Move the SCS.mdb (and possibly SCS.ldb) database from the c:Program FilesCommon FilesSoftalkData folder to the c:SoftalkSCSData folder.

7. Press the Start button, select Control Panel | Administrative tools. Right click Data Sources (ODBC) and select “Run as Administrator”. Again you will need to enter admin credentials.

8. Select the System DSN tab and double click “Softalk Collaboration Suite”. In the ODBC Microsoft Access Setup dialog box, press the Select… button and locate the c:SoftalkSCSDataSCS.Mdb file, which you recently moved. Press OK.

9. Press the Start button and in the search window type regedit and in the search results right click the regedit entry and select “Run as Administrator”. Again you will need to enter admin credentials. Select the key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWorkgroupShareEntries and in the right hand window double click the DataFolder entry and change its value to c:SoftalkSCSData. Then browse to HKEY_LOCAL_MACHINESOFTWARESoftalkWorkgroupShareSetup and in the right hand window double click the DataFolder entry and change its value to c:SoftalkSCSData.

10. In the command window (running under admin rights) enter “net start workgroupshare” followed by Enter.

11. You can now run the WorkgroupShare administrator and it will be using the same database as the service.

Was this article helpful?

Related Articles

Need Support?

Can't find the answer you're looking for?
Contact Support