Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xWebVirtualDirectory Fails to create a virtual directory if it already exists #331

Open
PraveenKalavai opened this issue Feb 8, 2018 · 4 comments · May be fixed by #533
Open

xWebVirtualDirectory Fails to create a virtual directory if it already exists #331

PraveenKalavai opened this issue Feb 8, 2018 · 4 comments · May be fixed by #533
Labels
bug The issue is a bug. in progress The issue is being actively worked on by someone.

Comments

@PraveenKalavai
Copy link

xWebVirtualDirectory Services
{
Name = "Services"
Website = $Node.WebsiteName
WebApplication = $WebApplication
PhysicalPath = "F:\docs\tfs"
Ensure = "Present"
DependsOn = '[xWebsite]NewWebSite'
}

Desired Behavior : The resource should detect the virtual directory exists, and skip it.

*Actual Behavior: It attempts to create the virtual directory, and throws an error saying to use the 'force' parameter.

Error :
VERBOSE:[SERVERNAME]: [[xWebVirtualDirectory]Services] Creating new Web Virtual Directory "Services".
Destination element already exists, please use "force" parameter to override.
+ CategoryInfo : InvalidArgument: (:) [], CimException
+ FullyQualifiedErrorId : Destination element already exists, please use "force" parameter to override.,Microsoft.IIs.PowerShell.Provider.NewVirtualDirectoryCommand

@johlju johlju added bug The issue is a bug. help wanted The issue is up for grabs for anyone in the community. labels Apr 27, 2018
@johlju
Copy link
Member

johlju commented Apr 27, 2018

Thanks for reporting this! Labeled this issue as help wanted so that someone in the community can run with it.

@SteveL-MSFT SteveL-MSFT added this to Help Wanted in powershell/dscresources May 14, 2019
@omiossec
Copy link
Contributor

Hi all,

I made some tests
If you leave WebApplication blank, it works as expected

       xWebVirtualDirectory Services
        {
        Name = "Services"
        Website = "Default Web site"
        WebApplication = ""
        PhysicalPath = "C:\web\"
        Ensure = "Present"
        }

It creates the virtual directory if not present, update it if needed or do nothing if the VD exists.

If you add a WebApplication, if the VD is not present it creates it under Webapplication name (ie /myApp/MyVD), but if this VD exists it throws an error.

The problem seems to be in the way the resource test the existence of the virtual directory

it uses

$virtualDirectory = Get-WebVirtualDirectory -Site $Website `
                                                -Name $Name `
                                                -Application $WebApplication

Where it should use something like

$virtualDirectory = Get-WebVirtualDirectory -Site $Website `
                                                -Name /$WebApplication/$Name `
                                                -Application 

May I try to send a solution?

@johlju johlju added in progress The issue is being actively worked on by someone. and removed help wanted The issue is up for grabs for anyone in the community. labels Oct 12, 2019
@SteveL-MSFT SteveL-MSFT removed this from Help Wanted in powershell/dscresources Nov 27, 2019
@blackspy21
Copy link

bump... still hitting this bug. Any progess? Or easy work around? My VD needs to exist under the web app

tommysor added a commit to tommysor/WebAdministrationDsc that referenced this issue Nov 8, 2022
Make `Set-TargetResource` switch between `WebApplication` '' and '/' as required by `New-WebVirtualDirectory` and `Remove-WebVirtualDirectory` respectively.

Fix dsccommunity#331
Fix dsccommunity#366

Similar to old (2019) pr dsccommunity#533
tommysor added a commit to tommysor/WebAdministrationDsc that referenced this issue Nov 9, 2022
Make `Set-TargetResource` switch between `WebApplication` '' and '/' as required by `New-WebVirtualDirectory` and `Remove-WebVirtualDirectory` respectively.

Fix dsccommunity#331
Fix dsccommunity#366

Similar to old (2019) pr dsccommunity#533
tommysor added a commit to tommysor/WebAdministrationDsc that referenced this issue Nov 9, 2022
Make `Set-TargetResource` switch between `WebApplication` '' and '/' as required by `New-WebVirtualDirectory` and `Remove-WebVirtualDirectory` respectively.

Fix dsccommunity#331
Fix dsccommunity#366

Similar to old (2019) pr dsccommunity#533
@tommysor
Copy link
Contributor

tommysor commented Nov 9, 2022

Theory: Use parameter WebApplication only if an application by that name exists in your site.

Not properly tested

Recreated in integration tests:

# Only relevant properties included
WebVirtualDirectory WebVirtualDirectory_WithProblem
{
	WebApplication = 'DummyApp'
	Name = 'dummy'
}
<!-- C:\Windows\System32\inetsrv\config\applicationHost.config -->
<site name="WebsiteForVirtualDirectory" id="2" serverAutoStart="true">
	<application path="/" applicationPool="DefaultAppPool">
		<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot" />
		<virtualDirectory path="/DummyApp/dummy" physicalPath="C:\inetpub\virtualdirectory" />
	</application>
	<application path="/WebApplication" applicationPool="DefaultAppPool">
		<virtualDirectory path="/" physicalPath="C:\inetpub\webapp" />
	</application>
# Only relevant properties included
# This results in identical applicationHost.config, but does NOT have the problem
WebVirtualDirectory WebVirtualDirectory_WorksFine_1
{
	WebApplication = ''
	Name = 'DummyApp/dummy'
}

# This puts the VirtualDirectory under the application "/WebApplication" in applicationHost.config
# This does NOT have the problem
WebVirtualDirectory WebVirtualDirectory_WorksFine_2
{
	WebApplication = 'WebApplication'
	Name = 'dummy'
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug. in progress The issue is being actively worked on by someone.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants