Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 6473 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows Server 2008 R2 SP1 webcid setup

aburrow

I'm trying to setup a webcid on a Windows Server 2008 R2 SP1 machine.

I've successfully got it working for windows Endpoint clients, but I can't for our Mac clients.

The log on the client only says "Could not contact primary server" error changes between "Server was not available" and "Server could not be found"

The IIS Log has the following

"

2013-03-26 05:34:24 137.166.68.29 GET /Sophos/OSXHomehttp/Sophos+Anti-Virus.mpkg/Contents/Packages/SophosAU.mpkg/Contents/Packages/SophosAUCLI8.0.1.pkg/Contents/Resources/preinstall - 80 - 220.233.4.17 <UA+a="Mac"+u="<domain\username>"+v="8.0.8.1"+/> 401 2 64 93
2013-03-26 05:34:24 137.166.68.29 GET /Sophos/OSXHomehttp/Sophos+Anti-Virus.mpkg/Contents/Packages/SophosAU.mpkg/Contents/Packages/SophosAUCLI8.0.1.pkg/Contents/Resources/preinstall - 80 - 220.233.4.17 <UA+a="Mac"+u="<domain\username>"+v="8.0.8.1"+/> 401 1 2148074254 31
2013-03-26 05:34:24 137.166.68.29 GET /Sophos/OSXHomehttp/Sophos+Anti-Virus.mpkg/Contents/Packages/SophosAU.mpkg/Contents/Packages/SophosAUCLI8.0.1.pkg/Contents/Resources/preinstall - 80 <domain\username>"+ 220.233.4.17 <UA+a="Mac"+u="<domain\username>"+v="8.0.8.1"+/> 404 17 64 93

"

A web browser can connect with no problems.

What setting am I missing?

:38791


This thread was automatically locked due to age.
  • 0

    Hello aburrow,

    I don't have an immediate solution, I'll try to help you with interpreting the log and maybe it gives you some ideas:

    AFAIK Macs try with authentication (as opposed to AU on Windows which always makes an unauthenticated request first) so the request should get a 200 reply. Looking at the substatus code (the number after the 40x) I see 2 (i.e. the detailed code is 401.2 which means logon failed due to server configuration), then 1 (simply logon failed but with a w32 code of 8009030e) and eventually with 404.17 which is rather obscure.

    Also the URL seems quite strange - for managed clients I'd expect both the subscription (Snnn) and ESCOSX in the path. Do you rewrite the URL somewhere? 

    Anyway, it seems that there's an issue with the authentication scheme used. According to Troubleshooting updating from Web CID issues Anonymous, Basic, Digest and Windows Authentication are all known to work correctly.

    HTH

    Christian

    :38803
  • 0

    QC,

    I've spent a few days investigating the error codes below thanks for that.

    At this point I don't think it's an Authentication issue.  Even turning a "Anonymous" doesn't resolve it.

    Looking at the log file and turning on directory browsing I beleive the issue is more to do with IIS not knowing how to handle the "pkgInfo" file.

    I've tried specific MIME maps, generic MIME maps and have installed a MS hotfix.  http://support.microsoft.com/kb/2646735

    The AppPool is set to use .NET Framework 2 so I don't think this hotfix has any effect.  I've also tried changing the AppPool to .NET Framework 4 still nothing.

    I'm not sure where to go from here.

    :38981
  • 0

    Hello aburrow,

    as you mention PkgInfo - looks like the files without extension are the ones causing troubles. You do have a wildcard MIME type defined (likely so, otherwise with .NET 2.0 you get a 404.3).

    In your first post you said a web browser can connect with no problems - does it indeed prompt you to open/save the file if you browse to one of the extension-less files? 

    Christian

    :38989
  • 0

    I don't like "unclosed threads" - not knowing whether a problem has been solved or worked around (and if, then how).

    I can add a potential solution to this one as I've encountered this problem just a few days ago. Server admins had applied some updates, a few days later a Mac user reported persisting update problems when outside (updates are internally over UNC/smb - furthermore the issue doesn't surface for IDE only updates). Turned out that a request for an extensionless file resulted in a 500 error. As it had worked before for quite some time and the configuration hadn't been touched I was somewhat miffed. Took a look at the Handler Mappings, suspected the ExtensionlessUrlHandler-Integrated-4.0. Restricting it to not handle GET requests made the 404.17 appear.

    For whatever reason I couldn't get the mentioned hotfix (it's available again today, must've been a glitch) so I searched for another solution. I was able to add a MIME Type with an empty extension but this didn't help. Eventually I stumbled over a forum thread where using just a dot for the extension is suggested - indeed, this solved the problem (dunno how long until another patch will break it again but for now it works).

    Christian

    :40325