In our case we are not so concerned about what SiteId="*" will result in wrt the actual SiteId value that gets generated and used when the msi determines its necessary to create the iis:WebSite.
What we are really interested in is the fact that including the SiteId="*" attribute, based on discussions in this thread and our test results over the course of the past day, results in the iis extension searching the host for whether or not the web site already exists using a case sensitive name that matches the Description attribute value specified. This is important behavior to us because w/o SiteId="*" attribute value in place what we found is that the iis extension would search the host for whether or not the web site already exists using the iis:WebAddress settings and this was undersirable because this is something that is not always predictable ad design time for all environments. Example being cases where ops creates/configures the web site in advance of the msi having every been run. Or we have cases where ops configures the web site left behind after an uninstall where iis:WebSite associated component has Permanent="yes" and then on next install we want to be able to find that site by name because the port settings lookup won't produce an accurate result. -----Original Message----- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Thursday, April 09, 2009 9:21 AM To: General discussion for Windows Installer XML toolset.; tomtr...@artizan.com Cc: Dmitry Frenkel Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings? I think this thread may be misunderstanding what SiteId="*" means. I means use the IIS6 default of setting the site id to the hash of the name, I don't believe it is triggering a search of the description. A site id of 1 is the default of the "Default Web Site" created when IIS is installed. The hashing algorithm can generate a duplicate site id in which case IIS adds one until it finds a free number. See here for more details: http://blogs.msdn.com/mpoulson/archive/2006/03/06/544893.aspx Neil -----Original Message----- From: Robert O'Brien [mailto:robert.obr...@microsoft.com] Sent: 09 April 2009 16:51 To: 'tomtr...@artizan.com' Cc: Dmitry Frenkel; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings? Thanks for the additional details and answers to questions. I think given iis supports to two web sites using the same name and differing only in case then it's the right thing to do to have SiteId="*" triggered searching for Description attribute value matches to also be case sensitive. Wrt our properties.wix entries to create references to existing web sites like the "Default Web Site" I think even there we will use SiteId="*" vs SiteId="1" because we really don't care what site id its living on (given that could change if you deleted it, added a different non default web site, and then recreated the default web site manually). We really just care about being able to get a reference to the well known and understood "Default Web Site" for things that we'd like the installer to stick under it versus our things we want going under our "<Deliverable> Web Site". We tested in our properties.wix using the following so that we'd setup our reference to the Default Web Site w/o any suggestion of us caring what iis:WebAddress settings it had in place and got a compiler error as it seems it is a requirement to a sub-element to a iis:WebSite element. <iis:WebSite Id="DefaultWebSite" SiteId="*" Description="Default Web Site" /> Switching it to the following works but then we have the iis:WebAddress port 80 setting/expectation. <iis:WebSite Id="DefaultWebSite" SiteId="*" Description="Default Web Site"> <iis:WebAddress Id="http" Port="80" /> </iis:WebSite> q1 - is the above iis:WebSite sub-elemented requirement expected? q2 - if so in this particular case since we have SiteId="*" in place to trigger the metabase search using the Description attribute value AND the fact that it's an iis:WebSite reference vs being part of a component can we expect that the iis:WebAddress element requirement in order to compile will really have no effect, e.g. it shouldn't matter whether or not at install time the default web site is configured with a port 80 binding. From: Thomas S. Trias [mailto:tomtr...@artizan.com] Sent: Wednesday, April 08, 2009 6:33 PM To: Robert O'Brien Cc: 'General discussion for Windows Installer XML toolset.'; Dmitry Frenkel; Kiran Challa Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings? I was pretty surprised to see the lstrcmpW there myself; however, it is entirely possible to have two sites where the MD_SERVER_COMMENT values differ only by case (or are even the same; hopefully the IIS Manager is keying sites by SiteId / metabase path and not by description). Providing more control over the comparison would require either overloading the SiteId further or introducing additional attributes. Of course, the default should be to behave as WiX does currently. Note that host header comparisons are also case sensitive, so an additional attribute sounds like the most feasible solution. 1. Correct 2. Correct. It's also nice if you configure the SiteId at installation time (perhaps by letting someone pick an existing site, or if you are upgrading an existing site. 3. What can I say; for my particular needs, I'm living as close to the bleeding edge as I can. Thomas S. Trias Senior Developer Artizan Internet Services http://www.artizan.com/ -------- Original Message -------- Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name -> Description attribute value versus port settings? From: Robert O'Brien <robert.obr...@microsoft.com><mailto:robert.obr...@microsoft.com> To: 'tomtr...@artizan.com<mailto:tomtr...@artizan.com>' <tomtr...@artizan.com><mailto:tomtr...@artizan.com>, 'General discussion for Windows Installer XML toolset.' <wix-users@lists.sourceforge.net><mailto:wix-users@lists.sourceforge.net> Cc: Dmitry Frenkel <dmitry.fren...@microsoft.com><mailto:dmitry.fren...@microsoft.com>, Kiran Challa <kicha...@microsoft.com><mailto:kicha...@microsoft.com> Date: 4/8/2009 8:15 PM Thanks for the additional clarification. This is pretty much exactly what we want and need. The case sensitive Description attribute search would preferably be case insensitive but this we can live with or file a bug or feature request against to have changed to be case insensitive To playback what I'm hearing and what Kiran is finding in tests so far using this information: 1. if we specify a SiteId="*" then the iis:WebSite Description attribute value gets used in a case sensitive search to see if a match exists before deciding to create a the site. Any child iis:WebAddress settings of iis:WebSite entries where SiteId="*" attribute is included will not affect the search to see if an existing instance of the web site is present before deciding to create a the site. 2. if we specify a SiteId="#" then the iis:WebSite syntax will look for explicitly for that SiteId to see if a match exists before deciding to create a new site. This is particularly useful in case where you'd like to creating iis:WebSite references to well known "Default Web Site" where SiteId="1" attribute setting can be used so that in the case of a w08 or w08r2 default web server role installation you end up referencing the "Default Web Site" as confirmed by executing either of the following commands: %windir%\system32\inetsrv\appcmd.exe list sites %windir%\system32\inetsrv\appcmd.exe list site "Default Web Site" /config:* Any child iis:WebAddress settings of iis:WebSite entries where SiteId="#" attribute is included will not affect the search to see if an existing instance of the web site is present before deciding to create a the site. 3. based on kiran's tests today the SiteId attribute processing doesn't appear to work in wix 3 official beta release 4805 but does work in newer builds such as 4923. -----Original Message----- From: Thomas S. Trias [mailto:tomtr...@artizan.com] Sent: Wednesday, April 08, 2009 5:57 PM To: General discussion for Windows Installer XML toolset. Cc: Dmitry Frenkel Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings? You are correct; "Default Web Site" is handled specially, and if you always want Site Id 0, that is what you should use. However, the effect of SiteId="*" is not exactly as advertised in the documentation. candle and light generate a -1 in the Id field of the IIsWebSite record within the MSI if the SiteId is "*". This causes ConfigureIIsExec to use the following search criteria when looking for the site in the metabase: mrCompare.dwMDIdentifier = MD_SERVER_COMMENT; mrCompare.dwMDAttributes = METADATA_INHERIT; mrCompare.dwMDUserType = IIS_MD_UT_SERVER; mrCompare.dwMDDataType = ALL_METADATA; mrCompare.dwMDDataLen = 0; mrCompare.pbMDData = NULL; where mrCompare is a METADATA_RECORD structure that gets passed to MetaGetValue in order to get the data with with which to compare the IIsWebSite record. The Id of -1 also causes the comparison of mrCompare.pbMDData to take place as a case sensitive Unicode comparison against the Description field. So, a hash of the description is not actually being used. Thanks, Thomas S. Trias Senior Developer Artizan Internet Services http://www.artizan.com/ -------- Original Message -------- Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings? From: Robert O'Brien <robert.obr...@microsoft.com><mailto:robert.obr...@microsoft.com> To: 'General discussion for Windows Installer XML toolset.' <wix-users@lists.sourceforge.net><mailto:wix-users@lists.sourceforge.net>, 'tomtr...@artizan.com<mailto:tomtr...@artizan.com>' <tomtr...@artizan.com><mailto:tomtr...@artizan.com>, Kiran Challa <kicha...@microsoft.com><mailto:kicha...@microsoft.com> Cc: Dmitry Frenkel <dmitry.fren...@microsoft.com><mailto:dmitry.fren...@microsoft.com> Date: 4/8/2009 6:31 PM + in case of a properties.wix declaration of a "Default Web Site" so that we have a way to do things against that well known iis7x site if/when we need to I'm guessing that we must use SiteId="0" in that case, vs SiteId="*", so that we always find use the site with name "Default Web Site" known to be site 0 regardless of what port and/or host header and/or ip bindings an operator has created on it for a given environment, e.g. <iis:WebSite IdÞfaultWebSite" Description="Default Web Site"><iis:WebAddress Id="http" Port="80" /></iis:WebSite> becomes just the following without the iis:WebAddress specifics? <iis:WebSite IdÞfaultWebSite" SiteId="0" Description="Default Web Site"></iis:WebSite> -----Original Message----- From: Robert O'Brien [mailto:robert.obr...@microsoft.com] Sent: Wednesday, April 08, 2009 4:19 PM To: 'tomtr...@artizan.com<mailto:tomtr...@artizan.com>'; 'General discussion for Windows Installer XML toolset.'; Kiran Challa Cc: Dmitry Frenkel Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings? Thanks this helps. Currently Kiran is testing this out to see if it provides the iis:WebSite behavior outlined below that we are looking for. Is there an current lkg build newer than the public wix 3 beta1 release 4805 that folks can switch to in order to ensure they have all the latest and greatest fixes that have gone in since 4805 but still be on a known to be good install? -----Original Message----- From: Thomas S. Trias [mailto:tomtr...@artizan.com] Sent: Wednesday, April 08, 2009 11:20 AM To: General discussion for Windows Installer XML toolset. Cc: Dmitry Frenkel Subject: Re: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings? Robert, Add SiteId=" as an attribute to iis:WebSite. SiteId String Optional attribute to directly specify the site id of the WebSite. Use this to ensure all web sites in a web garden get the same site id. If a number is provided, the site id must be unique on all target machines. If "*" is used, the Description attribute will be hashed to create a unique value for the site id. This value must be a positive number or a "*" or a formatted value that resolves to "-1" (for the same behavior as "*") or a positive number or blank. If this attribute is absent then the web site will be located using the WebAddress element associated with the web site. Thanks, Thomas S. Trias Senior Developer Artizan Internet Services http://www.artizan.com/ -------- Original Message -------- Subject: [WiX-users] is it a bug that iis:WebSite doesn't locate presence of existing website using just the Name attribute value versus port settings? From: Robert O'Brien <robert.obr...@microsoft.com><mailto:robert.obr...@microsoft.com> To: 'wix-users@lists.sourceforge.net<mailto:wix-users@lists.sourceforge.net>' <wix-users@lists.sourceforge.net><mailto:wix-users@lists.sourceforge.net> Cc: Dmitry Frenkel <dmitry.fren...@microsoft.com><mailto:dmitry.fren...@microsoft.com> Date: 4/7/2009 7:14 PM We have a service deliverable msi where optionally have some w08/iis70 "Default Web Site" vdir settings we want to apply and some "Site1 Web Site" and "Site2 Web Site" settings we want to apply (see relevant excerpt below). We need to allow for deployments where "Site1 Web Site" and "Site2 Web Site" already exist as a result of OPS having set them up in advance. This is to enable scenarios where all web sites are advertised on tcp/80 and tcp/443 and OPS uses environment specific IP or host header name settings to differentiate incoming requests. In our installer we won't know what those environment specific IP or host header name settings are. What we are finding is that the iis:WebSite extension uses iis:WebAddress port settings to determine if the site is already present. So in cases where all three iis:WebSite details in our code of iis:WebAddress portEUR defined, and no other unique setting such as ip or host header, they always end up latching onto and modifying the "Default Web Site". q1 - is this expected behavior for the iis:WebSite extension? q2 - if this is expected behavior is there some way to work around this so that we can get it looking for an existing install of the iis:WebSite using just the Name attribute value instead? q3 - if this is expected behavior is this something that has not previously had a bug filed against it to get fixed in some post wix3 official beta 3.0.4805.0 release since having iis:WebSite look for existing install of the site using just the Name attribute value presents a much more powerful story in terms of service deliverable msi's where you have to be able to install against cases where the only unique website thing you can know, want to have to know, at development time is the Name. <iis:WebAppPool IdïaultAppPool" Name="DefaultAppPool" /> <iis:WebSite IdïaultWebSite" Description="Default Web Site"> <iis:WebAddress Id=p" Port="80" /> </iis:WebSite> <Component Id=e1AppPool" Guid="ACF34F1A-5778-4A98-8AF9-7CF38A81AF6F" KeyPath="yes" Permanent="yes"> <iis:WebAppPool Id=e1AppPool" Name="Site1AppPool" Identity="networkService" /> </Component> <Component Id=e1" Guid="35BD9B02-7833-4CCE-9BC6-D8B8B49E5347" Permanent="yes"> <File Id=talledSite1.txt" Name="InstalledSite1.txt" Source="Resources\InstalledComponent.txt" KeyPath="yes" /> <!-- TODO: copy Site1Dir files into place here --> <iis:WebSite Id=e1WebSite" Description="Site1 Web Site" Directory="Site1Dir"> <iis:WebApplication Id=e1App" Name="Site1 Application" WebAppPool="Site1AppPool" Isolation="medium" /> <iis:WebAddress Id=e1WebAddress" Port="80" /> <iis:WebAddress Id=e1WebAddressSsl" Port="443" Secure="yes" /> </iis:WebSite> </Component> <Component Id=e2AppPool" Guid="510AD484-C0E6-441D-9E07-8B583D2207CA" KeyPath="yes" Permanent="yes"> <iis:WebAppPool Id=e2AppPool" Name="Site2AppPool" Identity="networkService" /> </Component> <Component Id=e2" Guid="AFBE602C-550C-43DB-A36A-BCEC66569967" Permanent="yes"> <File Id=talledSite2.txt" Name="InstalledSite2.txt" Source="Resources\InstalledComponent.txt" KeyPath="yes" /> <!-- TODO: copy Site2Dir files into place here --> <iis:WebSite Id=e2WebSite" Description="Site2 Web Site" Directory="Site2Dir"> <iis:WebApplication Id=e2App" Name="Site2 Application" WebAppPool="Site2AppPool" Isolation="medium" /> <iis:WebAddress Id=e2WebAddress" Port="80" /> <iis:WebAddress Id=e2WebAddressSsl" Port="443" Secure="yes" /> </iis:WebSite> </Component> ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net<mailto:WiX-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net<mailto:WiX-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net<mailto:WiX-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
