Rich,
I did not have a need to create sites, since for DotNetNuke we are used
to just creating applications under a previously existing site (a carryover
from our WinXP dev days). Like you I found it extremely difficult to figure
out how to manage different aspects of IIS7 with WMI, so I stuck with what
I needed for my demo, and left it at that. Definitely not for the faint
of heart.
Joe Brinkman
----------------------------------------------------------
DotNetNuke Corp. ASP.Net MVP
www.dotnetnuke.com
----------------------------------------------------------
Quote:
> Joe
>
> Thanks for the script. I was trying the WMI stuff locally on a Win
> 2008 box as member of everything so permissions shouldn't have been an
> issue.
>
> I've got the code to create an application using .NET instead of WMI
> and I must admit that the .NET solution seems much easier. Did you
> try creating a site with WMI at all?
>
> Thanks
>
> "Joe Brinkman" wrote:
> Quote:
>> RichS,
>> I did a demo at DotNetNuke OpenForce on using PowerShell to automate
>> installing
>> DotNetNuke. As part of that demo, I had a function that creates a
>> webapp
>> and adds it to the appropriate app pool.
>> function new-webapplication (
>> $AppPath,
>> $Directory,
>> $AppPool = "DotNetNuke",
>> $SiteName = "Default Web Site",
>> $Computer = ".",
>> [switch]$passthru ) {
>> $MC = [WmiClass]"\\$Computer\ROOT\WebAdministration:Application"
>>
>> # We need to ensure the AppPath starts with a / otherwise we will get
>> an
>> error
>> if ( -not $AppPath.StartsWith("/") ) { $AppPath = "/$AppPath" }
>> $mc.Create($AppPath, $SiteName, $Directory)
>>
>> #Now we need to add the application to an application pool
>> $appquery =
>> '\\$Computer\Root\WebAdministration:Application.Path="$AppPath",SiteN
>> ame="$SiteName"'
>> $appinstance =
>> [wmi]$ExecutionContext.InvokeCommand.ExpandString($appquery)
>> $appinstance.ApplicationPool = $AppPool
>> $appinstance = $appinstance.Put()
>> if ($passthru) { $appinstance }
>> }
>> In my testing and development, I found that the errors returned are
>> very obtuse and hard to understand. The biggest culprit - failing to
>> run the script with the proper permissions. Also note that I have
>> not tested the script against a remote server which would require
>> dealing with permissions, an area of WMI that I don't have experience
>> with. I will say that this was my first dealing with WMI in
>> PowerShell and it took me a long time to figure this out.
>> Personally, I found WmiExplorer to be a good starting point, but
>> there are so many parts of IIS7 that are very unintiuitive. If I
>> could have found the documentation on doing this with .Net classes, I
>> would have used them in a heartbeat. I am not sure if it will
>> matter, but I only tested this on IIS7 in Vista. I don't know if
>> there are any differences with Win2008
>>
>> One of the problems I had with the WMI implementation for IIS7 is
>> that it is different than the WMI classes for IIS6. To me, that
>> would have been the biggest benefit to WMI, using one script that
>> would work with both IIS6 and IIS7.
>>
>> HTH
>>
>> Joe Brinkman
>> ---------------------------------------------------------- DotNetNuke
>> Corp. ASP.Net MVP www.dotnetnuke.com
>> ----------------------------------------------------------
>> Quote:
>>> Theres no *must* about it
>>>
>>> I've already posted to my blog about using V2 remoting and the .NET
>>> Microsoft.Web.Administration namespace. Using appcmd via PowerShell
>>> remoting seems a backward step.
>>>
>>> I wanted to investigate the WMI provider for IIS 7 to see if it was
>>> any easier or gave any advantages - current conclusion is the .NET
>>> method is easier to understand and get working
>>>
>>> "Marco Shaw [MVP]" wrote:
>>>
>>>> RichS wrote:
>>>>
>>>>> I have been investigating using PowerShell to administer IIS 7.
>>>>> Using the Microsoft.Web.Administration namespace I have
>>>>> sucessfully created and deleted sites, applications and
>>>>> applicationpools - see recent posts on my blog for details.
>>>>>
>>>>> This code also works very nicely through the remoting features of
>>>>> PowerShell V2. Hurrah we're 2 for 2
>>>>>
>>>>> Now comes the problem - IIS 7 also exposes a WMI provider
>>>>>
>>>>> I have managed to do a certain amount through WMI and PowerShell
>>>>>
>>>>> $site = Get-WmiObject -Namespace "root\webadministration" -Class
>>>>> Site -Filter "Name = 'WTest1'"
>>>>>
>>>>> $site | Set-WmiInstance -Argument @{ServerAutoStart = "False"}
>>>>>
>>>>> $site.Stop()
>>>>> $site.Start()
>>>>> $site.psbase.Delete()
>>>>> Such as changing properties of the site stoppping & starting &
>>>>> deleting sites. The one point where I have hit a wall is creating
>>>>> a site using WMI. I have found a reference to doing it with
>>>>> VBScript
>>>>>
>>>>> http://www.iis.net/articles/view.asp...Administration
>>>>> -T ools/Scripting-IIS7/Managing-Sites-with-IIS7-s-WMI-Provider
>>>>>
>>>>> but I cannot duplicate this in PowerShell. I am open to
>>>>> suggestions (within resaon ;-) ) and would be extremely grateful
>>>>> if someone can point out what I am missing
>>>>>
>>>> Any particular reason you *must* do this with WMI? Using the v2
>>>> remoting, you could just use appcmd.exe.
>>>>
>>>> I am trying it out though. No luck so far either here, but I've
>>>> thought of a few things since last night, but I've not time to try
>>>> them until tomorrow evening or so.
>>>>
>>>> --
>>>> Microsoft MVP - Windows PowerShell
>>>> http://www.microsoft.com/mvp
>>>> PowerGadgets MVP
>>>> http://www.powergadgets.com/mvp
>>>> Blog:
>>>> http://marcoshaw.blogspot.com