Distribution Points blocking AppDeployToolkitMain.cs

It seems that a distribution point with default settings blocks .cs files by default. Because of this, admins have complained about not being able to deploy my packages because of the AppDeployToolkitMain.cs file. Since the people running the servers don’t want to change any settings on their distribution points I have to find a workaround. Has anyone found a good solution to this? I don’t want to have to roll back to 3.6.1.

I have never had this problem with default DPs I have built or heard of this problem from anyone else and quite a few people use the toolkit. I’m curious, if they were to change the default settings on the DP, what setting exactly would they change? I would like to take a look at this setting if there is one because it seems like a very strange thing to block a file extension that is simply a text file that contains C# code.

IIS does have a request filter for .cs set to false, but I’ve never had to modify this on any version of ConfigMgr 2012. I just verify some clients and AppDeployToolkitMain.cs is downloaded to the ccmcache folder.

I should add that this only seems to be a problem on ConfigMgr 2007, we haven’t had this issue with 2012.

File location:
%Windir%\System32\Inetsrv\Config\

Filename:
applicationHost.config

Section:
<requestFiltering>

Setting:
FileExtension cs allowed=False

They would have to switch it to True to get it to work. This is on a server 2008 applicationHost.config. The file extensions aren’t present in the Sever 2012 config file.

Okay, I guess I have no objection to changing the file extension for that file to a .txt or .xml or something. It will make context highlighting in text editors kind of inconvenient but if this is the default setup for IIS on a 2007 box I guess I can change it on our end.

Still, it is a pretty innocuous setting and it’s kind of silly for the server guys to take a hard line on not changing it. It is not too rare for advanced PowerShell scripts to have some C# code that they compile at run-time so this may be a problem they run into again.

If you create a ticket for this on GitHub, I will include it in the next release.

Muhammad, has this change been added to a recent version? We are experiencing this issue now as well, we’re at 3.6.8.

Thanks

-Craig