Successfully Implementing Shadow Folders in Windows 2003

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Thu Dec 09, 2004 12:18 pm

Is it possible this is related to the fact that it works as long as MySourceGear account is logged into the server - regardless of who else is logging in?
Jeff Clausius
SourceGear

ldudex
Posts: 10
Joined: Thu Jun 17, 2004 10:48 am

Post by ldudex » Thu Dec 09, 2004 1:09 pm

*sigh* Guess I jumped the gun when I said I got shadow folders working. I am experiencing the same problem now, getting the same crypto errors reported by Imar:

12/9/2004 10:15:03 AM <generic>: [<No Name>:1004] Vault's Shadow Folders encountered an exception attempting to login to the Vault Server for Repository ID 2. CryptoAPI cryptographic service provider (CSP) for this implementation could not be acquired.

I made the permissions changes outlined in the related blurb (http://support.sourcegear.com/viewtopic.php?t=231), but this didn't fix the problem either... I'm still getting the above errors.

One other thing that seemed very odd to me... I installed Vault when logged in under the custom vault account... when I log in using another account (such as admin), I don't see links to Vault anywhere, and I don't even see it in the Add/Remove Programs console. Something is definitely amiss with the way the installation is handled.

At this point, I think I'm about done with the entire Win 2k3 and Vault (with Shadow Folders) thing... I'll just consider Vault not being ready for Win 2k3, flatten the dev server and run Win 2k. At least I *KNOW* that works.

I apologize for getting everyone's hopes up on this one - it's unfortunate... I really wanted this to work, but it's obviously just not ready for prime time yet =(

jaaron
Posts: 5
Joined: Thu Nov 11, 2004 2:37 pm

Post by jaaron » Thu Dec 09, 2004 1:26 pm

All of this is confirming what I have suspected ever since trying to get shadow folders to work with 3.0: the ShadowFolderService is not running solely as the impersonated user (as set up either in the Application Pool or web.config file). I'm seeing the same symptoms as Imar Spaanjaars--shadow folders frequently breakdown with the "CryptoAPI" error--and I discovered another tidbit of information. My C: drive was filling up, and I found several Gigs of hidden folders in the following folder:

%APPDATA%/SourceGear/Vault_1/PluginWebService/

The purpose of this folder is described in

http://support.sourcegear.com/viewtopic.php?t=1219

The strange part is that this folder wasn't in the profile folder of my Shadow Folders user but rather the user that runs my SQL Server service! Does that mean that I need to set permissions for my SQL service user on all of the various folders described in the document at the beginning of this thread? This is getting to be very frustrating. :x

ldudex
Posts: 10
Joined: Thu Jun 17, 2004 10:48 am

Post by ldudex » Thu Dec 09, 2004 2:09 pm

ARGH! I was minutes away from wiping the dev machine, when I tried something super simple (after applying the crypto API fix mentioned in this thread with no success):

- Uninstall Vault, when logged into machine using custom ShadowFolderAccount
- Install Vault, when logged into machine using custom ShadowFolderAccount
- When prompted, did NOT upgrade existing sgvault DB, started WITH NEW ONE
- Manually added old files from original sgvault DB into new DB (building new versions of Repositories as needed) via the Client tool.

It works now. I can log in under different accounts, Configure Shadow Folders in the admin tool and the shadow folders actually sync up. Adding/removing files results in those files being added/removed from the shadow folder(s).

This sucks in that I've lost all history, but it DOES work now. So perhaps it's the dB "upgrade" process that's missing something on the setup process for v3.0? I dunno.

I'll continue down this path for a few days and see if some OTHER problem crops up. If not, good to go. I'll report back, regardless of result, good or bad. Hopefully we'll get this licked at some point.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Thu Dec 09, 2004 2:48 pm

ldudex wrote:When prompted, did NOT upgrade existing sgvault DB, started WITH NEW ONE
Yipes! I wouldn't recommend this, as nothing has changed regarding Shadow Folders. No one should wipe their database.

We're looking at this issue and hope to have more news shortly.
Jeff Clausius
SourceGear

Imar Spaanjaars
Posts: 9
Joined: Thu Dec 09, 2004 9:55 am

Post by Imar Spaanjaars » Fri Dec 10, 2004 2:58 am

Sorry for the late response. I am in a different time zone, so I was taking a nap while you guys were discussing all this interesting CryptoAPI stuff.

Anyway, the problem has returned. Updates are no longer shadowed to the shadow folder. I still can't confirm whether it has to do with logging into TS with a different account. I am not the only one connecting to the machine, so I can't tell for sure if it just stopped working, or that someone else logged in.

If you need more information, or want me to look at / test other settings, please let me now.

Really want to fix this.....

Imar

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Dec 10, 2004 9:16 am

As I mentioned above, we're working on this problem, and hope to have a solution very soon.

In the meantime, one thing that you may want to try as a temporary work-around -> placing IIS 6 in IIS 5.0 isolation mode. Testing has confirmed Vault 3.0 works correctly in IIS 5 on Windows 2000/XP, so I'm hoping this would also work when IIS 6.0 is in IIS 5.0 mode.
Jeff Clausius
SourceGear

Imar Spaanjaars
Posts: 9
Joined: Thu Dec 09, 2004 9:55 am

Post by Imar Spaanjaars » Fri Dec 10, 2004 9:20 am

jclausius wrote:In the meantime, one thing that you may want to try as a temporary work-around -> placing IIS 6 in IIS 5.0 isolation mode. Testing has confirmed Vault 3.0 works correctly in IIS 5 on Windows 2000/XP, so I'm hoping this would also work when IIS 6.0 is in IIS 5.0 mode.
Yes, I considered that, but it's not an option for me.

The server hosts a few ASP.NET applications, and I cannot afford to test or change this on a live server, as it's likely I'll run into other ASP.NET security and configuration troubles.

I'll wait for a solution.....


Imar

ldudex
Posts: 10
Joined: Thu Jun 17, 2004 10:48 am

Post by ldudex » Fri Dec 10, 2004 12:25 pm

Well, here's my final input for this subject for now... as jcclausius had stated, starting with a new DB actually did NOT solve the problem.

The problem clearly is a timing issue... once installed, I can use Vault Admin and Client tools with a 2003 machine that is running shadow folders just fine. I reinstalled Vault last night/this morning (it's all a blur at this point), verified all was well and went to bed for a while. I came back to Vault around 8 hours later -I tried redefining shadow folders, adding files, deleting files, nothing worked. I tried restarting IIS, crypto services and a few others just to see if I could get it working again and got no love at all.

I bumped IIS down to IIS 5 Isolation mode and can at least confirm THAT worked, but really kills one of the main advantages of using Server 2003 in the first place.

Here are some repro steps I can provide that (hopefully) may help you (sourcegear) isolate this problem:

After the shadow folder failure, I tried the following:

- Restarted IIS, Crypto services - didn't work
- Rebooted machine - didn't work
- Downgraded to IIS 5 Isolation Mode - DID work
- Upgraded back to IIS 6 (turned off Isolation Mode) - did NOT work

So at this point, I guess we're stuck with IIS 5 Isolation Mode. My only other thought was that perhaps the timeout period could be related to IIS 6 setting for the "Recycle Worker Process" interval (default of ~1100 minutes), but I don't have any more time to waste on this.

I wish you luck in figuring this out... it's going to be a doozy to debug, that's all I have to say ;-)

If you do wind up with a possible fix (something you've actually proven to fix this problem on your end), please let me know and I would be willing to help you out by testing the fix(es).

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Dec 10, 2004 12:51 pm

ldudex wrote:I bumped IIS down to IIS 5 Isolation mode and can at least confirm THAT worked, but really kills one of the main advantages of using Server 2003 in the first place.
That is good to know there is a current work around, which should be temporary in nature.
ldudex wrote:If you do wind up with a possible fix (something you've actually proven to fix this problem on your end), please let me know and I would be willing to help you out by testing the fix(es).
Keep an eye on this thread during next week. We have a lead on a problem, and hope to know something (possibly have a fix) by then.
Jeff Clausius
SourceGear

jaaron
Posts: 5
Joined: Thu Nov 11, 2004 2:37 pm

Post by jaaron » Fri Dec 10, 2004 1:02 pm

Another temporary workaround is to leave the ShadowFolderAccount logged into the machine. I know that's not feasible for some people, but it works if you have physical access to the server and can do it. You don't need to bump IIS down to IIS 5 isolation mode in that case.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Dec 10, 2004 4:43 pm

OK. We have a fix in the works. Initial testing shows that Shadow Folders is once again working.

We're not done testing all the different scenarios, so look for an updated Vault release sometime early next week.

BTW -> There does seem to be some discrepency of configuring Shadow Folders w/ .Net 1.1 and .Net 1.1 SP1.

The only thing I could do is use a new Shadow Folder Appplicaiton pool. I'll be updating the Shadow Folder FAQ with this new information.
Jeff Clausius
SourceGear

Guest

Post by Guest » Fri Dec 10, 2004 5:37 pm

jclausius wrote:OK. We have a fix in the works. Initial testing shows that Shadow Folders is once again working.
This is really great news. Thanks a lot for looking into *and* (hopefully) fixing this so quick.
The only thing I could do is use a new Shadow Folder Appplicaiton pool.
Are you saying that Shadow Folders only work when you configure a separate app pool, and you can't use impersonation?

Not that I mind, though. I find the app pool a much cleaner and secure solution that using impersonation.
I'll be updating the Shadow Folder FAQ with this new information.
There is a FAQ?? Can you tell me where to find it?


Thanks,

Imar

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Fri Dec 10, 2004 6:40 pm

Anonymous wrote:Are you saying that Shadow Folders only work when you configure a separate app pool, and you can't use impersonation?
This was not the case when we originally configured Shadow Folders to work with Vault.

However, in my testing today, I could not successfully get identity impersonation to work. So I gave up, and went with an application pool instead.
Anonymous wrote:There is a FAQ?? Can you tell me where to find it?
Here is the link for all KB articles - Knowledge Base Index of Topics

And the Win 2003 server KB article. Shadow Folders on Windows 2003 Server
Jeff Clausius
SourceGear

ldudex
Posts: 10
Joined: Thu Jun 17, 2004 10:48 am

Post by ldudex » Sat Dec 11, 2004 12:50 pm

You may want to remove the part of the "FAQ" regarding the Identity Impersonation section of the web.config file too, unless the fix will make that part work again :-)

Post Reply