GMS Solutions

Established in 1994, GMS prides itself on being one of the most accommodating and customer-centric email messaging vendors. We offer solutions for organisations of all sizes, and our approach to customer satisfaction has been recognised throughout our long term communities.

WorkgroupShare

WorkgroupShare lets Outlook users share (via synchronisation) their Outlook folders amongst one another without the need for Exchange Server. A user or an administrator can control which other users have access to their calendars, contacts, tasks, notes or email folders. WorkgroupShare is an Outlook collaboration product ideal for smaller companies seeking a cost effective folder sharing solution.

Softalk Mail Server

Softalk Mail Server is a high performance and dependable mail server. Its engine is database driven and so provides a much higher performance than other competing products. Its rich feature set includes: content filtering, email archiving, web-based email and anti-spam protection.

Products

Resellers

WorkgroupShare Fails to Synchronize When Using SSL

SYMPTOMS

Clients are unable to synchronize with WorkgroupShare using the Secure Sockets Layer protocol (SSL) and Diagnostics may report the following error message:

Unable to create secure socket to test connection to the WorkgroupShare server on localhost.

CAUSE

This error occurs because the SSL certificates installed on the server cannot be accessed by the WorkgroupShare application, or the certificate files have been corrupted.

RESOLUTION

To resolve this problem, the certificates need to be deleted from the Windows Certificate Store, and then re-created by running the WorkgroupShare Server Setup once again. WorkgroupShare needs to be installed while logged in as a local administrator and it must be installed to run as a service under that same account.

MORE INFORMATION

The Local System Account does not have access to the Microsoft Windows Certificate Store. Therefore, for WorkgroupShare to be able to run and use SSL it must be running as a Windows service under the context of a local administrator.

Moreover, if you run the WorkgroupShare setup while logged in as Bob who has local administrative access, and elect to run the WorkgroupShare service as user Bill who also has local administrative access, SSL would fail.

Why? When the certificates are installed, they are done so as the currently logged in user, and encrypted by the WPAPI.DLL using the key of that user. In this instance, the certificate would be encrypted using Bob's key, which is private. When WorkgroupShare tries to access the certificate store using the credentials of the account upon which it is running - Bill in this example - the service cannot do so, as Bill does not know Bob's private key, and therefore cannot access the certificate. As a consequence SSL will not function.

DETAILS

Create a local user account and give it local administrator access permissions. This account will be used to install and run the WorkgroupShare server program. Log into the WorkgroupShare server computer using this account and remove the existing WorkgroupShare certificates. To do this, you must first download the Microsoft MMC below, depending upon the operating system WorkgroupShare is running on:

Extract the contents from the downloaded zip file to a location of your choice, and run Certificates.MSC. If it fails to run, please open a command window, and enter the following command:

regsvr32 %systemroot%\system32\certmmc.dll

Underneath Console Root are three certificate stores (Certificates - Current User, Certificates (Local Computer), and Certificates - Service(WorkgroupShare)). Right click on each one in turn, and select Find Certificates from the context menu.

Accept the default search parameters, and in the Contains: field type:

WorkgroupShare

The results of the search will be populated in a list below. From this list, delete each certificate by right-clicking on it, and selecting Delete from the context menu.

As mentioned before, repeat this for each of the three certificate stores.

Once this has been completed, the WorkgroupShare Server component needs to be re-installed. Before doing so, however, please make a backup of your WorkgroupShare database. For SQL Server installations, please backup your database according to your database documentation. If you are using Microsoft JET, you can verify the location of your database file by following the steps given below:

Click Start >> Run and type: odbccp32.cpl

Click OK

Select the System DSN tab and double-click the SoftalkCollaborationSuite data source entry. The details window of the data source will show you where the WorkgroupShare database (SCS.mdb) is located.

When re-installing the application you are asked if you wish to run WorkgroupShare as an Executable or as a Windows Service. Select Windows Service. Next, you will be asked under which credentials the service should run as. The default option is to run the service as the Local System Account, but this needs to be changed if you wish to use SSL. Select to run the service under the user account created earlier.

Note that this user account needs to be specified using the notation of domain or local machine name\username

Continue to install WorkgroupShare. When installation is complete, open the WorkgroupShare Administrator, and do the following:

Go to Settings >> and then to the Server tab

Ensure that the Interface option is set to [All Interfaces].

Ensure that one of the options Listen on Secure Port Only or Listen on Both Secure and Non-Secure Ports is selected, depending on your requirements.

Ensure Secure Port is set to 8101.

Restart the WorkgroupShare Service by using the Services applet in Control panel (Administrative Tools).

Open the WorkgroupShare Administrator once again. Click Edit >> Run Diagnostics. If the same error message occurs, please contact Softalk Support.