I am having absolutely no luck getting SourceSafe internet working with IIS 7.0 on Windows Server 2008 at a client's site. I'm a .NET Architect, but the SysAdmin, who built the server and installed IIS and SourceSafe, failed to get it going, so I thought I'd have a go.
Configuring the SourceSafe internet server from SourceSafe Administrator is successful and the vrtual folder/application is created pointing to VssService.asmx in Program Files (x86). Therefore the creation wizard must be using WebDAV and SSL correctly in order to connect and install (If you turn SSL off on IIS and require SSL in SourceSafe Admin, the install fails as expected). I have installed the latest KB updates for Visual SourceSafe. Windows Server updates are up-to-date. I ensured that the srcsafe.ini file contains the correct URI. I have manually set the SourceSafe app to use the "Classic .NET AppPool" and have set "Enable 32-bit applications" to true for that AppPool.
Outlook Web Access (OWA) is installed as a 64-bit app on the same Default Web Site, using its own 64-bit AppPools. I manually installed the SourceSafe Internet web app in a new Site and virtual host on the IIS according to the instructions from http://msdn.microsoft.com/en-us/library/ms230398(VS.80).aspx, which I was referred to from http://alinconstantin.members.winisp.net/webdocs/scc/VSS_Internet.htm, but no change in behavior was experienced - i.e. the same 500 error at URI.
However, when the https://hostname.domainname/SourceSafe/VssService.asmx URI is called in a browser an error 500 page is returned. Accessing from Visual Studio causes an 8004005 error, the same as several of the previous posts on this issue, except that none of the fixes I have tried works (see last paragraphs).
The same error occurs when using SSL or not - I am pretty sure it is a 32-bit/64-bit problem or a OWA/SourceSafe conflict problem.
The Web log entry on the IIS for access to the URI via Visual Studio is:
2009-07-07 01:00:27 x.x.x.x GET /SourceSafe/VssService.asmx - 443 - x.x.x.x SourceSafe+Remote+MSSCCI+Client/1.0 500 24 50 0
The Event log actually records an OWA error each time the SourceSafe URI is accessed, which is weird, because OWA is working fine and using 64-bit onlt AppPools:
| |
|
| |
|
|
[ Name] |
Microsoft-Windows-IIS-W3SVC-WP |
| |
|
|
[ Guid] |
{670080D9-742A-4187-8D16-41143D1290BD} |
| |
|
|
[ EventSourceName] |
W3SVC-WP | |
| |
|
| |
Keywords |
0x80000000000000 | |
| |
|
| |
|
|
[ SystemTime] |
2009-07-07T02:12:43.000Z | |
| |
|
| |
Computer |
DGSYDSV03.datgel.local | |
| |
|
IsapiFilter |
C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll |
| |
|
ProcessorArchitecture |
x86 |
Event log description:
ISAPI Filter 'C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349
My client requires both OWA and SourceSafe over port 443 from a client site (on the other side of the world) that does not allow VPN through their firewall. Therefore, we require that OWA and SourceSafe co-exist on the same IIS instance, as we do not want the expense of a second server and/or Layer-5 switch. We do not want to roll back the server to Server 2003.
Basically, I've Googled myself stupid and can't get anywhere on this issue.
Any help appreciated.
VXPL