Shadow folders does not work after upgrade to Vault 4.1.2

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 10:52 am

And just to be clear, for my case http://localhost/VaultService will be fine since everything is running on the same server and our server does not have multiple web sites? Right?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Jun 20, 2008 10:54 am

Yes, that should be what you need.
Subscribe to the Fortress/Vault blog

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 10:55 am

Simple enough.

Thanks again!

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Just when you thought it was safe to get back into the water

Post by davenovak » Fri Jun 20, 2008 2:26 pm

Sorry to keep dragging this out, but the Vault Shadow Folder Service is still not working correctly. Though the Admin tool shows everything in the Shadow folder list and I can even successfully add new entries, target folders are never populated.

Also, if I attempt to update an existing entry, the update is ignored, yet no errors are reported through the UI and none seem to show up in either the Vault log or the Shadow Folder log files. However, looking at the system event log (under Application) reveals the following errors:

Code: Select all

Event Type:	Error
Event Source:	ASP.NET 2.0.50727.0
Event Category:	None
Event ID:	1334
Date:		6/20/2008
Time:		4:09:15 PM
User:		N/A
Computer:	RTGBUILD2
Description:
An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/1/Root/VaultShadowFolder

Process ID: 5124

Exception: System.Security.Cryptography.CryptographicException

Message: Keyset does not exist


StackTrace:    at System.Security.Cryptography.CryptographicException.ThrowCryptogaphicException(Int32 hr)
   at System.Security.Cryptography.SafeProvHandle._FreeCSP(IntPtr pProvCtx)
   at System.Security.Cryptography.SafeProvHandle.ReleaseHandle()
   at System.Runtime.InteropServices.SafeHandle.InternalFinalize()
   at System.Runtime.InteropServices.SafeHandle.Dispose(Boolean disposing)
   at System.Runtime.InteropServices.SafeHandle.Finalize()

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Code: Select all

Event Type:	Error
Event Source:	.NET Runtime 2.0 Error Reporting
Event Category:	None
Event ID:	5000
Date:		6/20/2008
Time:		4:09:15 PM
User:		N/A
Computer:	RTGBUILD2
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 mscorlib, P5 2.0.0.0, P6 471ebc5b, P7 4d82, P8 6, P9 udta330idobh2roz2ayvlcelag5agtls, P10 NIL.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 63 00 6c 00 72 00 32 00   c.l.r.2.
0008: 30 00 72 00 33 00 2c 00   0.r.3.,.
0010: 20 00 77 00 33 00 77 00    .w.3.w.
0018: 70 00 2e 00 65 00 78 00   p...e.x.
0020: 65 00 2c 00 20 00 36 00   e.,. .6.
0028: 2e 00 30 00 2e 00 33 00   ..0...3.
0030: 37 00 39 00 30 00 2e 00   7.9.0...
0038: 33 00 39 00 35 00 39 00   3.9.5.9.
0040: 2c 00 20 00 34 00 35 00   ,. .4.5.
0048: 64 00 36 00 39 00 36 00   d.6.9.6.
0050: 38 00 65 00 2c 00 20 00   8.e.,. .
0058: 6d 00 73 00 63 00 6f 00   m.s.c.o.
0060: 72 00 6c 00 69 00 62 00   r.l.i.b.
0068: 2c 00 20 00 32 00 2e 00   ,. .2...
0070: 30 00 2e 00 30 00 2e 00   0...0...
0078: 30 00 2c 00 20 00 34 00   0.,. .4.
0080: 37 00 31 00 65 00 62 00   7.1.e.b.
0088: 63 00 35 00 62 00 2c 00   c.5.b.,.
0090: 20 00 34 00 64 00 38 00    .4.d.8.
0098: 32 00 2c 00 20 00 36 00   2.,. .6.
00a0: 2c 00 20 00 75 00 64 00   ,. .u.d.
00a8: 74 00 61 00 33 00 33 00   t.a.3.3.
00b0: 30 00 69 00 64 00 6f 00   0.i.d.o.
00b8: 62 00 68 00 32 00 72 00   b.h.2.r.
00c0: 6f 00 7a 00 32 00 61 00   o.z.2.a.
00c8: 79 00 76 00 6c 00 63 00   y.v.l.c.
00d0: 65 00 6c 00 61 00 67 00   e.l.a.g.
00d8: 35 00 61 00 67 00 74 00   5.a.g.t.
00e0: 6c 00 73 00 20 00 4e 00   l.s. .N.
00e8: 49 00 4c 00 0d 00 0a 00   I.L.....

Code: Select all

Event Type:	Error
Event Source:	VsJITDebugger
Event Category:	None
Event ID:	4096
Date:		6/20/2008
Time:		4:09:16 PM
User:		DDCINTERNAL\buildmachine
Computer:	RTGBUILD2
Description:
An unhandled exception ('System.Security.Cryptography.CryptographicException') occurred in w3wp.exe [5124]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.

Check the documentation index for 'Just-in-time debugging, errors' for more information.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 02 00 5c 80               ..\€    
Any ideas what might be happening here? I really need to get Shadow Folders working are we are making the transition to Vault 4.1.x this weekend!

Any help is appreciated.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Jun 20, 2008 2:33 pm

A first recommendation is to make sure that Everyone has full access to

\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

and all of the files in it.
Subscribe to the Fortress/Vault blog

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 2:41 pm

Administrators, NETWORK SERVICE, and ASP.NET Machine Accont all have Full Control. Everyone has "special" access, which appears to be everything except for Traverset Folder / Execute File, Delete Subfolders and Files, Delete, Change permissions, and Take Ownership.

Since Everyone has the same exact permissions as found on our live Vault server (still running 3.5.2), I doubt this is the issue.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Jun 20, 2008 2:45 pm

I usually say Everyone, since I don't know which account is running your ShadowFolder Service. You should be able to check the Shadow Folder log file to find out what user the service is running as. Give that one full control.

Another factor is that the later .Net frameworks (3.0 and 3.5) seem to be more particular in needing access to that directory.
Subscribe to the Fortress/Vault blog

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 2:56 pm

I have a lead now into what the problem could be. Running under the Vault-configured application pool (VaultAppPool), Shadow Folders does indeed work. The identity used by VaultAppPool is NETWORK SERVICE.

I had the Vault Shadow Folder service running under my own application pool, which is configured with the identity of a domain user. This same domain user is in the local Administrators group and also part of the IIS_WPG group. This is the exact same domain account and configuration that we use on the live vault machine (running 3.5.2), which works without a hitch. I require this account because some shadow targets are computers on the network (not just the local hard drive).

But definitely the problem has something to do with the applicaiton pool and permissions.

Any other thoughts?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Jun 20, 2008 3:00 pm

Did you verify that the domain user has full control over that directory and all of the files in it?
Subscribe to the Fortress/Vault blog

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 3:37 pm

I agree that this likely has something to do with permissions on that folder or files contained therein. The folder itself has full permissions for Administrators, but the files do NOT have such permissions. Those seem to have permissions for only NETWORK SERVICE and ASP.NET Machine Account.

I'm hesitant to mess with permissions here too as I know that you can easily hose your machine by changing files in this folder.

Any idea as to why Administrators does not have access to these files? On our live Vault machine, Administrators seems to have full access.

davenovak
Posts: 222
Joined: Mon Jan 15, 2007 2:15 pm
Location: Atlanta, GA

Post by davenovak » Fri Jun 20, 2008 4:06 pm

It's working!

After giving ownership of all files in that folder to Administrators and then replacing permission entries on all child objects from the parent folder (which already had full permissions for Administrators), then rebooting, all is fine now. Permissions on these files is now the same on the parent folder (whose permissions I mentioned earlier).

I'm quite happy that you so quickly thought to check permissions for that folder. I cannot explain, however, why those files were missing the critical permissions that the parent already had. This is a brand new (i.e., clean) Windows 2003 R2 server install and that stuff should just be right.

I think I'll be fine now when doing the real upgrade over the weekend.

Many thanks (once again).

--Dave

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Wed Jul 16, 2008 3:56 pm

Thanks for posting your results.

Locked