Shadow folder problems

Jerry R · Post by **Jerry R** » Wed Jul 21, 2004 4:21 pm

I have two shadow folders setup on a build computer. Each one is fairly large, as they contain the whole source tree (two different versions). When I initially Added the two shadows folders from the Vault server machine, the first one proceeded without a hitch, but on the second one, I got a "The underlying connection was closed: An unexpected error occured on a receive" message after it had been working on updating for a while.

Checking the build computer, only about 1/4 of the tree had been copied to the machine. I deleted the shadow folder that failed from the list of shadow folders and re-added it. Again I got the same error, but this time it appeared to have copied the whole tree. I deleted and added it again one more time, and the third time no error message.

However, when I add a file to Vault, it does not end up being copied to the build machine. Here's shadowfolder.log for when I added the file:
-------------------------
Initializing Client Instance... @ 21-Jul-04 17:26:10

Client Instance Initialized! @ 21-Jul-04 17:26:10

Verifying Repository... @ 21-Jul-04 17:26:10

Repository verified! @ 21-Jul-04 17:26:10

Retrieving Delta... @ 21-Jul-04 17:26:10

Access to the path "SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin" is denied. @ 21-Jul-04 17:26:11
------------------------------

Here's sgvault.log for when I added the file:
------------------------------
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
BeginTx beginning transaction
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
BeginTx returned: Success
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
VaultServiceBase.VaultRequestAddFile returned: Success
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Uploading file.
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
VaultFileUpload.aspx encountered: Success
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Ending transaction
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Creating plugin thread...
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
VaultServiceBase.VaultResponseAddFile returned: Success
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Retrieved 2 pluginInfos for this type
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Calling plugin at location :http://localhost/VaultShadowFolder/Vaul ... rvice.asmx
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
EndTxSuccess
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Getting repository Structure.
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
GetRepositoryStructure returned: Success
----21-Jul-04 17:26:10 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
Login
----21-Jul-04 17:26:10 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
GetUserOptions returned: Success
----21-Jul-04 17:26:10 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
GetRepositories returned: Success
----21-Jul-04 17:26:10 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
Getting repository Structure.
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Getting list of checkout changes.
----21-Jul-04 17:26:10 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
GetCheckOutListChanges returned: Success
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
GetRepositoryStructure returned: Success
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
VaultFileDownload starting
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
GetLatest wrote 0 bytes to the Response Stream
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
Ending download process
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
EndDownloadProcess returned: Success
----21-Jul-04 17:26:11 admin--surat.wn.ui.net(10.1.80.2)--SSL Disabled
Logout
----21-Jul-04 17:26:11 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Exception in plugin thread : System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.UnauthorizedAccessException: Access to the path "SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin" is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.Directory.InternalCreateDirectory(String fullPath, String path)
at System.IO.Directory.CreateDirectory(String path)
at VaultClientOperationsLib.CacheMember_Repository.SerializeCacheMember(Object o, DateTime& lastSyncTime)
at VaultClientOperationsLib.CacheMember.SaveObjectToDisk(Object o)
at VaultClientOperationsLib.CacheMember_Repository.SaveIfNewer()
at VaultClientOperationsLib.TreeCache.Save()
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Int32 id, String username, String uniqueRepositoryID, Boolean doRefresh, Boolean updateKnownChangesAll)
at VaultClientOperationsLib.ClientInstance.Logout()
at VaultShadowFolder.VaultShadowFolderService.OnEndTx(Int32 repID, Int64 txID)
at VaultPluginLib.VaultPluginServiceBase.EndTxEvent(Int32 nRepID, Int64 nTxID)
--- End of inner exception stack trace ---
----21-Jul-04 17:26:11 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Exiting plugin thread
----21-Jul-04 17:26:18 jerry--rubi1j-xpg.wn.ui.net(10.1.30.52)--SSL Disabled
Logout
------------------------------

rubi1j-xpg.wn.ui.netis the machine from which I added the file. surat.wn.ui.net is the vault server. From the log, it seems that the problem is that it is trying to access this plugin service from rubi1j, which it doesn't have permission to. But why isn't the access being done from surat? What do I have configured wrong, and is this related to the "underlying connection" error I got when I first Added the shadow folder?

I believe I followed the directions in the "Configuring Shadow Folders for UNC Paths" FAQ correctly, but please let me know if I missed anything.

-Jerry

Post by **jclausius** » Wed Jul 21, 2004 9:28 pm

Off the top of my head, I'd say that Shadow Folder's web.config is not correctly running under identity impersonation.

Let's take a look at it.

Can you :
1) Make a copy of your web.config file found in the Shadow Folder's Web App / Virtual directory
2) Modify the copy - cross out the password (fill it with asterisks or some other character)
3) Upload the copied / modified web.config file to the forum or send it to me via e-mail (see e-mail button below this post)

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 8:59 am

Here's the web.config. I removed most of the comment blocks for brevity, but that's all I removed:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<compilation defaultLanguage="c#" debug="false" />
<customErrors mode="RemoteOnly" />
<authentication mode="None" />





<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<httpRuntime executionTimeout="86400" maxRequestLength="10240" useFullyQualifiedRedirectUrl="false" minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100" />
<identity impersonate="true" userName="UIC\vault-shadow" password="[censored]" />
</system.web>
<appSettings>
<add key="shadowfolder_login" value="admin" />
<add key="shadowfolder_password" value="[censored]" />
<add key="shadowfolder_vaultserver" value="http://surat.wn.ui.net/VaultService" />
<add key="shadowfolder_workingfolderassociations" value="Shadow Folder Associations">
<rep repid="1">
<sfa assoc_key="1:$/metamorph/hts/database-\\alice\ftp\pub\uic\screening\scripts" reppath="$/MetaMorph/HTS/database" localpath="\\Alice\ftp\pub\uic\screening\scripts" readonly="True" repid="1" />
<sfa assoc_key="1:$/metamorph/mm62-\\build-xpg\mm62" reppath="$/MetaMorph/MM62" localpath="\\Build-xpg\mm62" readonly="True" repid="1" />
<sfa assoc_key="1:$/metamorph/mm-\\build-xpg\mm" reppath="$/MetaMorph/MM" localpath="\\Build-xpg\mm" readonly="True" repid="1" />
</rep>
</add>
</appSettings>
</configuration>

Post by **jclausius** » Thu Jul 22, 2004 9:20 am

Can you log in as UIC\vault-shadow, and check the existence of the following folder - %APPDATA%\SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 9:38 am

I logged onto the vault server machine as UIC\vault-shadow and verified that that folder exists, and I was able to CD to it from a shell prompt.

edit: actually I logged in as vault-shadow@uic

tbreyman · Post by **tbreyman** » Thu Jul 22, 2004 11:03 am

We were experiencing the same problem yesterday. We have finally resolved it. Here are the steps we took...

1. Installed Vault on a Vanilla Windows 2003 Server using an Administrative account. Received the above error when trying to add the Shadow Folder.

2. Configured the Vault Shadow Service to use a Custom Domain Account per the FAQ. Still received the error.

Here, we noticed that Vault had added application data to the account that was used to install Vault in Step #1 above (e.g. c:\documents and settings\adminaccount\application data). We added the Vault Shadow Service account we created in step #2 to the Administrators group (so that it would gain access to the Admin accounts Application Data) and tried again --- SUCCESS.

It seems that at some point (becuase we did several installs), vault put service specific information in the application data of the account that did the Vault installation. This is clearly wrong (a service should not need to have rights to the application data of the installing account). In any case, we are up and running.

Hope this helps.

Todd Breyman
Software Architect
SunGard Insurance Systems

Post by **jclausius** » Thu Jul 22, 2004 12:48 pm

Access to the path "SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin" is denied.

Let's focus on this error. It can be caused by a couple of problems:

1) Does the path does not exist at all times?. After logging in as vault-shadow, make a note of the actual path for "%APPDATA%\SourceGear\Vault_1\PluginWebService". Now log out, and log in as an administrative account. Does the path for vault-shadow's %APPDATA% still exist?

OR

2) The UIC\vault-shadow account does not have read/write permissions to the "C:\Documents and Settings\IMPERSONATION_ACCT\Application Data\SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin"

OR

3) Something is still incorrectly configured for Shadow Folder's for identity impersonation or the vault-shadow account does not have full user privileges.

By design, the Vault Shadow Folder Web service runs the Vault client to update the files. A requirement of the Vault client is full access to the %APPDATA% of the user's profile.

Now in IIS 5.0, an ASP.Net account runs under the local account ASPNET. This account has all the information available for user profile information. However, the ASP.Net process model changed in IIS 6. IIS 6 introduced a "lower priority" type of account named NETWORK_SERVICE. By default this account does not have the correct permissions to run the Vault Shadow Folder client. So, identity impersonation is used to correctly run the Vault client.

With that said, the Custom Account used for identity impersonation must have all the normal permissions a user would have. Additionally, when the user logs into the system, Windows will create the profile (including %APPDATA%) for that account.

However, with the errors you mentioned, there is something still wrong with either identity impersonation or the Windows Account itself. In general, the error should look like - Access to path "C:\Documents and Settings\IMPERSONATION_ACCT\Application Data\SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin" is denied

Because the error message is missing the full path for %APPDATA%, I'm guessing the impersonation or the account cannot find profile data when the Vault client is launched from ASP.Net under impersonation.

Does the vault-shadow account have local/domain privileges as a normal user? Would adding vault-shadow to the local Users group help?

tbreyman · Post by **tbreyman** » Thu Jul 22, 2004 1:45 pm

In our environment (not to be confused with the original posting), which is Windows Server 2003 and IIS 6.0, the C:\Documents and Settings\[IMPERSONATION ACCOUNT]\Application Data\SourceGear folder does not exist (even after logging in to the account).

We next performed the following steps
- log into the [IMPERSONATION ACCOUNT]
- install the client
- run the client

The C:\Documents and Settings\[IMPERSONATION ACCOUNT]\Application Data\SourceGear folder now exists and has \Vault_1 child folder which itself has a Client child folder. There is still no folder for PluginWebService.

As I not in the posting above, it appears that the VaultShadowFolder service is accessing it's application data from

C:\Documents and Settings\[INSTALLATION ACCOUNT]\Application Data\SourceGear

not

C:\Documents and Settings\[IMPERSONATION ACCOUNT]\Application Data\SourceGear

Is it possible that the installation program creates the SourceGear folder in the current Application Data folder (i.e. the one that belongs to the [INSTALLATION ACCOUNT]) and creates a configuration entry (in the registry, the database, a web config file, ...) that tells the Shadow Folder service where the Application Data is located? If so, this is obviously a problem since one account should not access the Application Data of another account.

We are thinking that if we clean the system (once again) and reinstall Vault while logged into the [IMPERSONATION ACCOUNT] that everything will be wired up correctly. What do you think?

Todd Breyman
Software Architect
SunGard Insurance Systems

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 2:02 pm

I tried adding the shadow-vault account to the administrator group like Todd suggested, and at first I thought it didn't have an effect. But later I discovered that in fact now most people's changes update the shadow folders properly. However, when I check in a file from the machine in my office (which is not the vault server), logged into my own account, I still get the same access denied message.

It appears to work from other people's machines, but not my own.

Jeff, as for your suggestions, I verified that the path exists. %APPDATA% = C:\Documents and Settings\vault-shadow\Application Data\ when logged in as vault-shadow. vault-shadow does have r/w permission for that directory (I was able to create/delete a folder in it). Of course, this is after adding vault-shadow to the admin group.

Post by **jclausius** » Thu Jul 22, 2004 2:09 pm

So, while logged in as vault-shadow, you could not read/write to the %APPDATA%\SourceGear... until you added it to the admin group?

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 2:14 pm

I don't know if I could r/w that directory before vault-shadow was added to the admin group. I tried that before your comprehensive reply came in. Do you want me to remove the admin privileges and check again?

Post by **jclausius** » Thu Jul 22, 2004 2:27 pm

tbreyman wrote:Is it possible that the installation program creates the SourceGear folder in the current Application Data folder (i.e. the one that belongs to the [INSTALLATION ACCOUNT]) and creates a configuration entry (in the registry, the database, a web config file, ...) that tells the Shadow Folder service where the Application Data is located?

No. The Vault client / server installations do not create any of the %APPDATA% information. The %APPDATA% information is created by a "run" of the Vault Client, the Vault Admin tool, or a run of Shadow Folders.

tbreyman wrote:We are thinking that if we clean the system (once again) and reinstall Vault while logged into the [IMPERSONATION ACCOUNT] that everything will be wired up correctly. What do you think?

That shouldn't really matter as the %APPDATA% directory for the Custom .Net account won't exist until Shadow Folder are configured.

The key is to run Shadow Folders under a Windows account which has read/write access to its own %APPDATA% directory.

Post by **jclausius** » Thu Jul 22, 2004 2:29 pm

Jerry R wrote:I don't know if I could r/w that directory before vault-shadow was added to the admin group. I tried that before your comprehensive reply came in. Do you want me to remove the admin privileges and check again?

If you wouldn't mind. - Just see if you can create directories / files etc under %APPDATA%\\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin while logged in as vault-shadow.

What if you gave the vault-shadow account direct security permissions (full control) to the %APPDATA%\ directory? Can you now create directories / files?

What groups is vault-shadow a member of? What if Vault-Shadow was a member of the "Users" group or "Domain Users" group?

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 2:37 pm

Ok, I'll try removing the admin privs and and instead giving vault-shadow full control of the APPDATA-based directory, and then try making it a member of User and Domain Users. I'll check r/w capability at each step.

Any ideas on why the shadow folder updating is now working from some machines but not from at least one other?

Post by **jclausius** » Thu Jul 22, 2004 2:45 pm

Here are some possible causes off the top of my head:

1) Changes are taking place in a folder which has not been configured for shadow folders.

2) Changes are taking place in a different repository than what has been configured for shadow folders.

3) Changes are taking place on a different Vault server than what has been configured for shadow folders.

Can you verify the change set transaction did take place in the sgvault.log?