Successfully Implementing Shadow Folders in Windows 2003

ldudex · Post by **ldudex** » Wed Dec 08, 2004 2:00 am

After fighting with getting shadow folders to work under Windows Server 2003, I FINALLY succeeded (weeks later). I decided to document the process so that other users who are experiencing the same problems no longer have to cull the support forum and waste endless hours trying to get shadow folders to work.

I apologize in advance for this document being in Word format, but it was the easiest way for me to get it out the door.

I would *HIGHLY* encourage the SourceGear documentation team to supply a document similar to the one I have written IN THE USER DOCUMENTATION. The shadow folder feature is widely used, and since Windows Server 2003 is the new Microsoft server platform of choice, there really needs to be complete, easy to follow documentation regarding this process.

That being said, I'm NOT claiming to be an expert AT ALL. I just want to try to save users the pain that I dealt with =)

dan · Post by **dan** » Wed Dec 08, 2004 8:27 am

Thanks for posting this. Sorry the doc isn't so good for Win2k3. We will try to get this integrated into our main help as time allows.

ldudex · Post by **ldudex** » Wed Dec 08, 2004 1:03 pm

No worries... I just wanted to provide a complete set of procedures in the interim to help people get it working =) From past experience, I know documentation often takes the back seat to feature sets =)

ldudex · Post by **ldudex** » Wed Dec 08, 2004 2:38 pm

Apologies in advance for this, but I *did* miss one critical step...

You also need to add FULL CONTROL permissions to the root folder where you shadow folders live... for instance, d:\www or d:\www\MyProjectName if you want to set permissions on a per-project basis.

I've updated the version of my document already in this post, so it now includes this omitted step

ldudex · Post by **ldudex** » Wed Dec 08, 2004 2:48 pm

I've updated the document to v1.02 to add a bit more detail to the setup process.

Thanks go to Imar Spaanjaars for going through a test run of the document for me =)

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 7:03 am

I followed the steps as outlined in the great tutorial that ldudex wrote, and it looks like Shadow Folders work correctly.

Once I check in a file, it becomes availabe in my shadowed folder.

However, after a while (an hour or so, don't know for sure), it no longer works. I can check in a file successfully, but it doesn't get copied to the shadow folder anymore.

I can make it work again when I log in with my custom ASP.NET account through Terminal Services. Right after I log in, edit and check in another files, it gets copied correctly.

Is this a known issue with a work around? This limitation makes Shadow Folders nearly unusable....

I am using version 3, both on the server (which runs on Server 2003) as on the client.

Imar

Post by **jclausius** » Thu Dec 09, 2004 8:38 am

Are the destination folders locally or on a network share? If on a network share, are all machines on the same Domain? Is the impersonated user a Domain User?

Can you try a sample on a local disk directory, and see if that exhibits the same problem?

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 8:46 am

Hi Jeff,

Thanks for your response.

The Shadow Folder is located on the same machine. Basically, I have SQL Server, IIS and Source Gear running on the same machine. The machine is a standalone Windows 2003 server and is not a DC and not connected to a domain.

In the mean time, I am no longer sure whether it's a time issue. The problem may also be caused by someone else logging into the server with a different (Admin) account than my custom Source Gear account I created. I still have to confirm this is really the case, but it looks like it.....

Imar

Post by **jclausius** » Thu Dec 09, 2004 9:07 am

Can you find the ShadowFolder log file on the local machine? I believe it is in the Custom .Net's %TEMP% directory. Are there any errors in the log file?

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 9:34 am

Interesting; didn't know this was all logged. (BTW, the log file is not the custom user's %temp% folder, but in %windor%\Temp\VaultShadowFolderService.txt)

Anyway, this is part of the log file:

12/9/2004 2:50:17 PM <generic>: [<No Name>:3576] Vault's Shadow Folders encountered an exception attempting to login to the Vault Server for Repository ID 4. CryptoAPI cryptographic service provider (CSP) for this implementation could not be acquired.
12/9/2004 2:50:17 PM <generic>: [<No Name>:3576] Vault's Shadow Folders tried / failed to log in to the Vault Server for 11attempts, and is giving up. It is possible, Shadow Folder directories may not be synchronized with the Vault Server.

Looks like a permission issue to me.

After I logged in to TS again, I edited a file, and checked it back in. The file was updated correctly, and the log file says:

9-12-2004 16:32:17 <generic>: [<No Name>:2020] GetEntryAssembly() returned null; not logging assembly name

If you need more information, let me know. I really love to see this issue fixed as it is stopping me from a successfull SG roll out.....

Imar

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 9:53 am

Interesting; didn't know this was all logged. (BTW, the log file is not the custom user's %temp% folder, but in %windor%\Temp\VaultShadowFolderService.txt)

Anyway, this is part of the log file:

12/9/2004 2:50:17 PM <generic>: [<No Name>:3576] Vault's Shadow Folders encountered an exception attempting to login to the Vault Server for Repository ID 4. CryptoAPI cryptographic service provider (CSP) for this implementation could not be acquired.
12/9/2004 2:50:17 PM <generic>: [<No Name>:3576] Vault's Shadow Folders tried / failed to log in to the Vault Server for 11attempts, and is giving up. It is possible, Shadow Folder directories may not be synchronized with the Vault Server.

Looks like a permission issue to me.

After I logged in to TS again, I edited a file, and checked it back in. The file was updated correctly, and the log file says:

9-12-2004 16:32:17 <generic>: [<No Name>:2020] GetEntryAssembly() returned null; not logging assembly name

If you need more information, let me know. I really love to see this issue fixed as it is stopping me from a successfull SG roll out.....

Imar

Post by **jclausius** » Thu Dec 09, 2004 9:54 am

Can you verify the user has read/write permissions on the %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys as well as the edb3f753ca89beb7d17f32a80a447d75_* file found in this directory.

You may want to temporarily assign READ/WRITE to the "Everyone" account, and then see if it works.

Note - From your original description, it is possible the problem may exist on the Shadow Folder side of things. If you log onto the Windows Server the Custom.Net account, you should see the %APPDATA%\Microsoft\Crypto\RSA directory. What are the permissions there? Also, what happens if you temporarily assign READ/WRITE to the "Everyone" account here?

Also, if you log into the machine under a different account, can you verify the Custom .Net's directory still exists?

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 10:27 am

(Sorry for the double post, something went wrong)

I checked the settings you asked me to check. I temporarily made my custom MySourceGear account an Admin, so I don't think it's a direct permissions problem on the folders.

But I tested the following:

1. %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
MySourceGear account has full permissions, also on the file you mentioned. Not only through the Admin group, but also as a separate account.

2. %APPDATA%\Microsoft\Crypto\RSA
MySourceGear account has full permissions

3. When I log in with a different account the %APPDATA% folder for the MySourceGear account still exists.

However, as soon as I logged out again with the other account, the updates didn't work anymore.

Whooaaaahh

More ideas?

Imar

Post by **jclausius** » Thu Dec 09, 2004 10:34 am

Just to clarify what has been done so far:

1) Shadow Folders is running under "identity impersonation" for the Account MACHINE\MySourceGearAcct. Is this done in Shadow Folder's web.config or under the Identity tab of Shadow Folder's App Pool?

2) When logged in to the 2003 server as MACHINE\MySourceGearAcct, Shadow Folders works correctly, but when logging out, the Shadow Folder operations fail, and the Shadow Folder Log shows errors regarding CSP Provider during the same time period?

Imar Spaanjaars · Post by **Imar Spaanjaars** » Thu Dec 09, 2004 10:54 am

Yes, I believe that sums it up.

Here's what I have done:

1. Followed the document ldudex wrote

2. Created a separate Application pool in IIS running under MySourceGear account

3. Changed the IIS site to use the MySourceGear account (I have created a separate SourceGear site for SoureGear)

4. Checked the settings you described in this thread.

5. Configured Shadow folders in SG; mapped $ to D:\Inetpub\wwwroot\MyShadowedSite

Now, when I log in through Terminal Services with my SourceGear account, and log off (or not, doesn't matter), Shadowing works and the changed file ends up in D:\Inetpub\wwwroot\MyShadowedSite.

However, as soon as I log in with another user account, shadowing breaks.

I just tried it again, and it seems to work even after I logged in as another user. So, it either works now, or it's not (only) related to the logon / logoff issue, but maybe a time issue.

Imar

SourceGear Support