Shadow folders does not work after upgrade to Vault 4.1.2
Moderator: SourceGear
Just when you thought it was safe to get back into the water
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:
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.
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 help is appreciated.
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.
\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
and all of the files in it.
Subscribe to the Fortress/Vault blog
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.
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.
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.
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
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?
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?
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
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.
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.
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
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