VDir - putting it under non "Default Web Site"

Topics: IIS and Web Services
Feb 26, 2015 at 4:21 PM
Edited Feb 26, 2015 at 4:24 PM
I have an orchestration published as WCF web service. As SharePoint is installed on the same server, I followed a co-worker's advice and set it up under a website called "Services Website" which has bindings for Port 9000 and SSL Port 9443. I ran an MSI deploy on my dev machine, and the site got restored under "Default Web Site" which is under port 80.

Is there a way to make it go back to it's original web site location?
And also then to have different websites/ports/certificates on local deploy vs QA and PROD deploy? Or do those changes need to be done post-deploy?

Thanks
Neal Walters
http://MyLifeIsMyMessage.net (My new blog site)
Coordinator
Feb 26, 2015 at 4:36 PM
Hi Neal,

Up to v5.5, you'll need to determine the IIS metabase path, like IIS://localhost/w3svc/1/Root (you need that site ID number), and override the IISMetabasePath property. That will at least direct it to the correct website. Hopefully the custom ports won't cause further trouble.

Thanks,
Tom
Feb 26, 2015 at 5:39 PM
Thanks Tom. Not sure I understood your answer.

I found this page on your site, http://biztalkdeployment.codeplex.com/workitem/8991, so I think you are telling me to add the IISMetabasePath in my .btdfproj file.

Now, what value to put in it? I've been Googling trying to learn how to find my metabase path, no luck yet. Some people talking about installing Metabase Explorer, but looks like it needs some SDK. How do I find the site ID number and the IIS metabase path?

I found this file: C:\Windows\System32\inetsrv\config\applicationHost.config, which shows the structure of the sites. Are the sites just numbered in the order found there?

Thanks,
Neal
Feb 26, 2015 at 5:59 PM
Edited Feb 26, 2015 at 6:01 PM
I think I found answer here - http://blog.eldert.net/create-webservice-in-non-default-website-using-btdf/.
In IIS, right click Website - Manage WebSite, Advanced Settings, then ID is the number.

So far, I working on local deploy. For QA/PROD, I might need to as described here: https://biztalkdeployment.codeplex.com/discussions/237263

Neal
Feb 26, 2015 at 6:32 PM
Need some more help on IISMetabasePath, can't seem to find doc on it.

If I put it under VDirList it built MSI but didn't take effect. If I put outside of VDirList, I get bulid error MSB4035: The required attribute "Include" is empty or missing from element <IISMetabasePath>.

Thanks,
Neal
Coordinator
Feb 26, 2015 at 6:39 PM
Edited Feb 26, 2015 at 6:39 PM
The number in the metabase path should be the id="x" from the applicationHost.config on the <site> element. IISMetabasePath is a property, so it goes inside a PropertyGroup. It's global, so it affects all IIS deployments.

Thanks,
Tom
Feb 26, 2015 at 7:09 PM
Edited Feb 26, 2015 at 7:10 PM
Thanks, but not gaining any ground here. I'm running BTDF 5.5 on BT2010, IIS 7.5. I'm building the MSI, and running on my dev machine in order to pass the user/pass from screens 4/5 of the modified InstallWizard.xml file.

I put the IISMetabasePath at the top like this:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Installer" ToolsVersion="4.0">
<PropertyGroup>
<Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
<Platform Condition="'$(Platform)' == ''">x86</Platform>
<SchemaVersion>1.0</SchemaVersion>
<ProjectName>eSecuritelIn</ProjectName>
<ProjectVersion>1.0</ProjectVersion>
<IncludeOrchestrations>False</IncludeOrchestrations>
<IncludeTransforms>False</IncludeTransforms>
<IncludeVirtualDirectories>True</IncludeVirtualDirectories>
<IncludeSSO>True</IncludeSSO>
<UsingMasterBindings>True</UsingMasterBindings>
<RequireXmlPreprocessDirectives>False</RequireXmlPreprocessDirectives>
<ApplyXmlEscape>True</ApplyXmlEscape>
<IISMetabasePath>IIS://localhost/w3svc/4/Root</IISMetabasePath>
</PropertyGroup>

and my VDirList looks like this:


<ItemGroup>
<VDirList Include="*">
  <Vdir>eSecuritelIn</Vdir>
  <Physdir>..\IISVirtualDir</Physdir>
  <AppPool>eSecuritel</AppPool>
  <AppPoolNetVersion>v4.0</AppPoolNetVersion>
  <VDIR_UserName>$(VDIR_UserName)</VDIR_UserName>
  <VDIR_UserPass>$(VDIR_PassWord)</VDIR_UserPass>      
</VDirList>
</ItemGroup>

Now I'm getting same error as here: https://biztalkdeployment.codeplex.com/discussions/396074
And no website is built anywhere.

targets(1754,5): error MSB4018: The "CreateVirt
ualDirectory" task failed unexpectedly.\r [C:\Program Files (x86)\Teleplan eSec
uritelIn for BizTalk\1.0\Deployment\Deployment.btdfproj]
C:\Program Files (x86)\Teleplan eSecuritelIn for BizTalk\1.0\Deployment\Framewo
rk\BizTalkDeploymentFramework.targets(1754,5): error MSB4018: System.Runtime.In
teropServices.COMException (0x800700B7): Cannot create a file when that file al
ready exists.

Thanks again for your help and patience.
Neal
Feb 26, 2015 at 7:15 PM
Just had another thought. If you are inserting an IIS-application into an existing site, then why mess with the app pool. That site would already have an app pool, and we probably wouldn't want to change it.

Neal
Coordinator
Feb 26, 2015 at 7:35 PM
Go into IIS Manager and completely delete the virtual directory, then manually re-create it and see if that helps. IIS 7.x has two distinct structures that look like one in IIS Admin -- a virtual directory and an application. The application lays on top of the virtual directory. Internally, IIS represents them as two objects.

I think this "Cannot create a file when that file already exists" can happen when those two IIS objects are out of sync, so sometimes it requires cleanup. If a redo in IIS Admin doesn't work, you may need to use appcmd.exe to clear out both the vdir and application.

If the AppPool already exists, it just tries to update the configuration.

Tom
Feb 26, 2015 at 9:18 PM
Still totally stuck.

I deleted, created, deleted, reran MSI same issue.

I did the following:
appcmd list site c:\test\sites.txt
appcmd list vdir c:\test\vdirs.txt
appcmd list app c:\test\apps.txt
I inspected all files, and my desired name "eSecuritelIn" is not there.

This is what the client test app calls: https://somedomain.com:9443/eSecuritelIn/myservice.svc.

I created a small MSBuild file to repro the problem without having to deploy, undeploy repeatedly:

<Project DefaultTargets="DeployVirtualDirectory"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="c:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\Microsoft.Sdc.Common.tasks"/>
<UsingTask AssemblyFile="c:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.Tasks.dll" TaskName="CreateVirtualDirectory" />
<PropertyGroup>
   <IISMetabasePath>IIS://localhost/w3svc/4/Root</IISMetabasePath>
   <Vdir>eSecuritelIn</Vdir>
   <Physdir>e:\Source\neal.walters\DefaultCollection\B2BTeamProject01-SCRUM\Dev\eSecuritel\eSecuritel_In\IISVirtualDir</Physdir>
</PropertyGroup>    
<Target Name="DeployVirtualDirectory">
   <CreateVirtualDirectory MetabasePath="$(IISMetabasePath)" Name="$(Vdir)" Path="$(Physdir)" />
</Target>
</Project>

When I run MSBUILD against above file, I get error if I specify <Vdir>eSecuritelIn</Vdir>, but almost any other values works fine.

I manually removed these items from that file, restarted IIS, reran the test MSBUILD, and same issue.

So it exists somewhere, but I have no idea where else to look.

I searched c:\windows\System32\inetsrv\config for the string 'eSecuritelIn' and kept seeing the ApplicationHost.congfig file.
But then a very mysterious thing. If I ran lister, a tool to browse the file, I would see those bytes still in the file. But if I opened the file with NotePad++, those bytes were not there. So I decided to reboot... No good.

Then I read warning in the file: The <customMetadata> section is used internally by the Admin Base Objects (ABO) Compatibility component. Please do not modify its content. So I guess I need to find out how to use ABO now to delete these items?

Neal
Coordinator
Feb 26, 2015 at 9:53 PM
If you just open applicationHost.config in Notepad++, do you find W3SVC/4/ROOT/eSecuritelIn anywhere in the customMetadata section? I guess that's used by the IIS 6 Compatibility feature of IIS, which (up to) v5.5 utilizes. If that's the only place you find eSecuritelIn, I'd try deleting those lines.
Feb 27, 2015 at 2:30 PM
Edited Feb 27, 2015 at 2:31 PM
Tom,
That's what I tried to describe above. It's in the section that says "Please do not modify its content.". I didn't see that warning at first, and I did remove the reference to it. I rebooted, and deploy issue remained. That's when I saw the odd scenario that browse the file with LISTER showed the data still there, and showing the file in NotePad showed that data gone.
Looks like I need a tool to clean it up. Powershell doesn't show it, AppCmd doesn't show it. ABO looks like a possibility but a lot of work (only supports C and VB6?)
This is one of those cases where I think a manual process might be better than me spending multiple days on this.
Or, when I talk to the team that deploys to prod, I'll discuss with them about creating a new Website instead of reusing the old one. Hopefully it's own my dev machine that has this issue.
Neal
Coordinator
Feb 27, 2015 at 6:07 PM
I'd suggest a remove and reinstall of the IIS 6 Compatibility features to see if it clears up the data issue. Or, use BTDF v6.

Tom
Feb 27, 2015 at 6:50 PM
Remove and reinstalled II6 Compatibility - no impact.

I'm trying to see if any IIS wizard chime in here:
http://stackoverflow.com/questions/28769213/cleanup-metadata-in-iis-unclear-if-app-is-there-or-not

I think I'll put on hold until I talk to our prod admins. Need to know what they want in other environments.
Even if I get it working on my dev machine, they might want different website and SSL certs of course on other machines.

Neal
Mar 2, 2015 at 1:44 PM
All is well now. I did the exact same thing I did a few days ago, edited the part of the file that says not to edit, and this time the changes "took".
Neal
Coordinator
Mar 2, 2015 at 2:52 PM
OK, good to hear. Sounds like caching of some sort within the IIS compatibility framework. Frustrating!

Thanks,
Tom