VaultPro loses its configuration settings

[sharpcon]

My team has been successfully using VaultPro V8.0.1 on Windows 7 Professional (64-bit) for a number of years. We use the concurrent development style.

Recently, on a number of occasions and for a number of users, some things have started to go wrong.

Occasionally when returning to the PC following an overnight hibernation or when reopening the application after a few days, I have seen files that were previously marked as "edited" being shown as "renegade".

Upon close inspection, I could see that all of my option settings had been altered. By laboriously changing the settings back to their original configuration, normality was restored and I was able to continue.

1. Please can you throw any light on what might be happening? It is now happening to someone every week or two and although we seem to have a work-around, it is very tedious to restore the settings.
2. Where is the options file stored? I cannot find it on my PC, so I wonder whether it might be held on the server.

Thanks

[Tonya]

Hello,

Can you think of anything new that was applied to your network when the issue started to occur? Any new Windows updates? Are the machines desktops or VM's? Exactly what options are not being saved? The problem only seems to occur when the machine has been idle for some time? What if the user closes the client and reopens it?

When you are using the default settings in Vault, when a file is edited without a check out, the file takes a status of Renegade. Is there any kind of application that is running through the night that is possibly editing the files?

Thanks,

Tonya

[sharpcon]

Thank you for your reply.

I am not using the default settings, but use the concurrent development style. It looks likely that when the issue occurs, all settings return to defaults.

I am unaware of any network changes, but that side of things is largely out of my control. However, if you could tell me where on a Windows 7 PC (or on the server) the options are saved, it could help me debug where the problem lies.

[jclausius]

Some settings are in the user's registry (HKCU\Software\SourceGear\VaultPro...) and some of those user settings (that would apply to a work-style) are stored on the server.

Is it possible something is deleting the registry hive after a restart or coming out of hibernation?

[sharpcon]

The VaultPro client is run mostly from Windows 7 Professional laptops that are connected either directly to the corporate network or remotely via a VPN.

Two frequent users have experienced the problems as described, in which the user settings apparently revert to defaults. There has been no indication of any other problem with the PCs. Under normal circumstances, Vault is often left open when the machine is hibernated and the session continues without any problem when Windows is resumed.

If I am to get further, I would appreciate some more information about the server side file location where the work-style user settings are stored, as that appears to be the area that is causing the issue.

[jclausius]

Is it possible they hibernate and the laptop is on one workgroup / domain, and then it is powered back on on a different workgroup / domain?

If so, is it possible the user's registry is switching accounts?

For example:

SOURCEGEAR\jclausius
WORKGROUP\jclausius

might be 2 different distinct accounts with distinct registry settings. It will have to be something you have to track down. I guess you could export that registry key to a file just before hibernation. Export the registry key after hibernation, and do a DIFF to see how the entries have changed.

Also, to verify, you are using concurrent development style, you do NOT use Check Out locks correct? Check Out locks are tied to a user's machine/domain(or workgroup). And when that setting is changed, for example when a laptop is suspended and removed from a corporate network, upon a start-up, the Checked Out item will appear as Renegade since it was checked out to an identifier which Vault will find different.

[sharpcon]

VaultPro Issues

We have two issues with VaultPro.

1. Losing the settings, which results in "Renegade" files. This is the problem I reported at the start of this thread. Restoring the settings appears to temporarily fix the problem.
2. Logging onto Vault remotely often fails. This is a long-standing problem that has never been resolved. I believe that it is independent of (1), but I include the information for completeness.

Your responses have mentioned PC hibernation as a concern. Please note that we have been successfully working this way for several years without incident.

We work either in the office or from home. Both the corporate network and the home office network use a workgroup named WORKGROUP.

When working in the office and connecting directly to the corporate network, logging into Vault works every time.

When working remotely, the corporate network is accessed via a VPN. For many years, access to the various network shares has always worked via the VPN, but logging onto VaultPro has been problematic for unknown reasons. We assume that this is a separate issue from the problem I am reporting in this thread.

To clarify, we use the concurrent development style. Whenever the problem manifests itself, the settings revert to default (I believe). Changing the settings back to concurrent (along with many other settings) seems to temporarily fix the problem and allows us to work.

We have been using this version of VaultPro (V8.0.1 build 30299) for several years without major incident. The "Rengade" issue is a fairly recent problem. It has been seen by two users, both in the office and whilst working from home. See the Case Study below for an example of how it is manifest.

Case Study

On Friday 14/8, my laptop was in the company office, connected directly to the corporate network and I used VaultPro without any problems. At the end of the day, the PC was hibernated (as usual).

On Monday 17/8, my laptop was switched back on in my home office. I successfully connected to the corporate network via the VPN, but VaultPro could not be contacted and the server connection attempt repeatedly timed out. This problem persisted throughout the day and also during Tuesday. At the end of each of these days, the laptop was hibernated.

On Wednesday 19/8, my laptop was switched back on in my home office. I successfully connected to the VPN and this time, also to VaultPro. However on this occasion, the "Renegade" problem had come back. Changing all of the settings fixed the problem and allowed me to work. At the end of the day, the PC was hibernated.

On Thursday 20/8, my laptop was switched back on in my home office. I successfully connected to the VPN and also to VaultPro. Everything worked normally.

Registry

I took before and after registry exports for the HKEY_CURRENT_USER>Software>SourceGear>VaultPro>Client>Settings key. The only difference between when the problem was present and after I had changed the settings was the "FormOptions" entry, which I believe relates to what is visible on the screen:

"Renegade" problem present:
"FormOptions"="(FormOptions.SubCategory,-1)(FormOptions.SelectedCategory,0)(FormOptions.ListViewSccPaths,(SmartListView.Column.Watched Paths.width,275)(SmartListView.ColumnOrders,Watched Paths))"

"Renegade" problem "fixed":
"FormOptions"="(FormOptions.SubCategory,-1)(FormOptions.SelectedCategory,14)(FormOptions.ListViewSccPaths,(SmartListView.Column.Watched Paths.width,275)(SmartListView.ColumnOrders,Watched Paths))"

Question

Is there a single file that contains the server side user settings? Is there a reason why VaultPro might be overwriting the file, perhaps if it decides that the file has become corrupted? Is there anything further you can suggest that might help us to narrow down the source of this recent issue?

[sharpcon]

The following is in response to Tonya's post on Mon Aug 17, 2020 8:12 pm, which I probably did not adequately answer.

I am in touch with the IT department to determine whether anything new was applied to the network when the issue started to occur. So far I have no information about this.

The client PCs are laptops running Windows 7 professional 64-bit. This operating system no longer receives security updates from Microsoft.

The options in question ARE being saved, but are occasionally being changed without my knowledge or consent. The options relate to the Concurrent development style that we use and I understand that these are stored on the server. I would like to know where.

The only edits to my files are made by me when the settings are set to Concurrent style, so the files are marked as "Edited". When I reconnect to VaultPro at a later date, the file status sometimes changes to "Renegade" because the settings have reverted to Check-out/Check-in. There is no application running that can edit my files, but in any case, doing so would not cause any problems when using the Concurrent style, but only if the settings have reverted to Check-out/Check-in.

The root cause appears to be the fact that the concurrent settings are being reset to defaults. The question is why that might be and why it has only started to happen relatively recently.

[sharpcon]

Some server version information from the IT department:

• VaultPro server: V8.0.1.30299 (64-bit).

• Windows Server 2012 R2 Standard.

[Tonya]

Hello again,

Can you please email us using support@sourcegear.com? We have a SQL query we'd like for you to run and would prefer to take this offline.

Thanks,

Tonya