I started having a problem with my OSD Build/Capture task sequence where the Install Software Updates step was hanging at Installing Updates 1 of 50... It would never progress past that. I looked at the IIS logs on my DPs and noticed that there were numerous PROPFIND requests coming from the client that received 401 errors. I checked to make sure that my web site was configured to allow anonymous propfind, and it was. I also checked the XML file that contains these settings as I read that frequently the XML file does not update correctly - it was configured with allow anonymous propfind set to true. Still, I had the same problem. Then, as a troubleshooting step, I enabled Anonymous Authentication on the DPs web site. This fixed the problem and my Build/Capture completed successfully. This is a problem though because now, I am able to map a drive to any DP folder without authentication. Am I required to allow anonymous authentication to my DPs in order for Install Software Updates to work during the Build/Capture trask sequence? I know if has something to do with anonymous propfind, but how can I allow anonymous propfind without removing authentication for GET and HEAD and the rest? PROPFINDS all show up 401 error unless I enable Anonymous Authentication. Domain clients during deploy phase and later in production work fine because they reauthenticate with the Computer$ account and don't rely on anon access to the DPs.

Wow - Anonymous Authentication has changed itself back to disabled on its own. Configmgr must be adjusting the permissions on the SMS_DP_SMSPKGX$ web site? Possible? I'm taking it on over to the OSD forum...

If I check the box on the DPs "Allow clients to connect anonymously (Required for mobile device clients), then the Install Software Updates task works during the build process. it also means that the DP WebDAV site is accessible without authentication from any computer on my network - that is not cool. Does installing Software updates during the OSD build sequence really require me to enable that "Allow clients to connect anonymously?" it is weird because all the packages for OSD (like the MDT Tools, the WIM, the Configuration Settings) all download fine and authenticate using the Network Access Account. The Software updates, however hang on downloading 1 of 50 when that anon box is unchecked. On the IIS logs of the DPs, the machine running the build process drops about 90 PROPFIND lines with 401 errors. There are never any patch related GET commands for the Intall Software Updates process, just failed PROPFIND on all three of my DP. As soon as I enable that Allow anonymous, it works fine. I am also amble to go to any computer on the network and type net use * http:\\FQDN.TO.DP.com\ SMS_DP_SMSPKGD$ and map a drive to all my distribution packages - unauthenticated - so I can't leave it like that... What to do?

I don't think boundaries are the issue, but mine are all defined as subnet boundaries - I do not use AD site boundaries. If it were a boundary problem, then I don't think the other packages like drivers and MDT script packages would be loading - and they are. Also, it is finding the DPs because it is doing a PROPFIND for all the patch packages - I can see the requests in the IIS logs on the DPs. The logs on the clients list 3 (the correct number of) DPs with both http and smb style sources. If any of the settings were wrong with regards to SLP and MP, then I don't think enabling Anonymous access would fix the problem. If you are missing the SLP, the client is unable to find the SUP and you never get to the downloading section- they can't complete a scan if the slp is not defined. I looked at that link. Solutions 4 and 6 are interesting and at least they are something to try. As soon as I enable Anonymous authentication on the DPs, the task runs fine, so to me that seems like an authentication problem or a misconfiguration on the DPs, but I have been over and over that WebDAV configuration utility lots of times with no positive results.

Hi Todd just wanted to see if you ever found an answer or solution to this? I am actually having the same issue at the moment. Thanks, BrandonBrandon Linton |http://myitforum.com/cs2/blogs/brandonlinton/default.aspx | MCTS - SCCM, MDT, AD

Same issue here, but with standard software distribution, not specific to OSD. On our Win2003 servers, if you open the IIS on the default website > properties > directory security > "Authentication and access control", hit the EDIT button, I see "Enable anonymous access" and the Username is filled with IUSR_ServerName, with a password configured. This is how we've always configured the 2003 server Distribution points. Just got off the phone with MS IIS support and they said anonymous is a No-no. I said that's how we've always done it. The below website does not mention anonymous authentication. http://technet.microsoft.com/en-us/library/cc431377.aspx#Install_WebDAV This website does, but it references use for mobile device clients and IBCM clients. We aren't supporting either. http://technet.microsoft.com/en-us/library/bb693984.aspx So what's the verdict on domain clients and IIS 7 distribution points? Enable Anonymous authentication or not? If not, then how do we get our clients to access package content on the servers?nick

I go strictly by this http://technet.microsoft.com/en-us/library/cc431377.aspx#Install_WebDAV I do not enable anonymous John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|

So, the problem described in the above thread is resolved by the recently released hotfix: http://support.microsoft.com/kb/2509007. What issue are you seeing Nick? Perhaps a new thread is in order.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Wow - Anonymous Authentication has changed itself back to disabled on its own. Configmgr must be adjusting the permissions on the SMS_DP_SMSPKGX$ web site? Possible? I'm taking it on over to the OSD forum... Todd, Where's your post for this? Anonymous Authentication is reverting to disabled on it's own for us too. Wondering if you found out why.nick

Yes, ConfigMgr is doing this. It does this for a lot things including ACLs on its own directories.Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys

Funny. MS IIS team told us they didn't know why and redirected us to the SCCM team; who told us to put the domain computers in our "users" group on the distribution points so that the windows authentication would work. I did that and have not had any issues; however, IIS miraculously stopped resetting the anonymous authentication setting. Would love to find out what was actually doing this.nick

Yes, ConfigMgr is doing this. It does this for a lot things including ACLs on its own directories. Jason | http://myitforum.com/cs2/blogs/jsandys | Twitter @JasonSandys Hi Jason, May I know more about how / when ConfigMgr would reset the anonymous settings? I've got this problem too, and 've opened a case with MS. But MS replys that SCCM is NOT doing this and refer me to open another case with IIS team to resolve that. And IIS engineer can't help me much on who is resetting the settings. So can you provide more hints on this? Thx. Regards, Pat