I'm creating a powershell script so I can create website hosting with a single command using the IIS Powershell Management Console.
I have the commands I need to create the IIS Site and add bindings for the domain names etc...
The one piece of the puzzle I'm missing though is how to change the default Logging directory from %SystemDrive%\inetpub\logs\LogFiles to my own folder that's not on the boot drive of the server.
After extensive searching I expected to find a command along the lines of the following pseudo powershell
New-ItemProperty IIS:\Sites\MyNewSite -name logging -value #{format='W3C';directory='d:\sites\site\logs';encoding=UTF-8}
Please could you show me with an example how you change the logging folder in the IIS Powershell Management Console
Thanks in advance
Import-Module WebAdministration
Set-WebConfigurationProperty "/system.applicationHost/sites/siteDefaults" -name logfile.directory -value $logdir
While testing the answer from this thread, toggling options via IIS Manager and PowerShell, I stumbled on something that has been hidden to me. In IIS Manager, choosing Configuration Editor and making a change, allows the IIS Manager to generate and display the script for the change in C#, JavaScript, AppCmd.exe and PowerShell. Just click the Generate Script option.
[]
For changing an individual web site's logFile configuration, the original post was nearly correct. Instead of New-ItemProperty, use Set-ItemProperty, like so...
Set-ItemProperty "IIS:\Sites\$SiteName" -name logFile -value #{directory=$LogPath}
For changing the server-wide default settings, see Andy Schneider's answer.
For more information about the options available, see this IIS.net article.
This works as well, using the WebAdministration Module
Import-Module WebAdministration
$site = gi IIS:\Sites\MyNewSite
$site.Logging.format='W3C'
$site.Logging.directory='d:\sites\site\logs'
$site.Logging.encoding=UTF-8
$site | set-item
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Administration")
$iis = new-object Microsoft.Web.Administration.ServerManager
$web = $iis.Sites["test"]
#set new logpath, must be existing
$web.LogFile.Directory = "F:\Logfiles\"
$iis.CommitChanges()
If you host multiple sites on a single server and want them to all log to the same log file, the process is quite different. It took some digging to find clues here and here, so I thought I would leave a description behind for anyone else with this need.
The following two statements will combine logs for all of your websites into a folder e:\log\w3svc.
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter 'system.applicationHost/log' -name CentralLogFileMode -Value 'CentralW3C'
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter 'system.applicationHost/log' -name centralW3CLogFile.directory -value 'e:\log'
Related
On Azure Portal, I am able to setup path-based rules which have some default setting, and a list of sub-rules (UrlPathMap).
Each of those sub-rules has a name, paths, backend pool, and HTTP setting that have to be configured.
As I can see I can update this map easily through Azure Portal.
I want to be able to create such sub-rules dynamically from code as part of the application installation. I would prefer to do this directly from .NET (ASP.NET Core 3.1) application, but Azure CLI or Azure Powershell script should be OK for me as well.
At this point, I tried to use Microsoft.Azure.Management.Fluent library, Azure CLI and Azure Powershell but I do not see the direct option to do what is need.
Will be really glad to get some help here.
According to my test, we can use the following PowerShell script to create a sub-rule.
Connect-AzAccount
$groupName=""
$gatewayName=""
$poolNmae=""
$httpName=""
$pathRuleName=""
# get original sub-rule in your path rule
$appgateway=Get-AzApplicationGateway -Name $gatewayName -ResourceGroupName $groupName
$pathmap=Get-AzApplicationGatewayUrlPathMapConfig -ApplicationGateway $appgateway -Name $pathRuleName
$t =$pathmap.PathRules.ToArray()
# add a new sub-rule to the path rule
# 1. get the require backendpool or backendhttp settings
$pool=Get-AzApplicationGatewayBackendAddressPool -Name $poolNmae -ApplicationGateway $appgateway
$http=Get-AzApplicationGatewayBackendHttpSetting -Name $httpName -ApplicationGateway $appgateway
# 2. create the sub-rule
$r=New-AzApplicationGatewayPathRuleConfig -Name "rule01" -Paths "/path" -BackendAddressPool $pool -BackendHttpSettings $http
$t += $r
# 3. update the path rule to add the new sub rule
Set-AzApplicationGatewayUrlPathMapConfig -ApplicationGateway $appgateway -Name $pathmap.Name -PathRules $t -DefaultBackendAddressPool $pool -DefaultBackendHttpSettings $http
# 4. make the update effective
Set-AzApplicationGateway -ApplicationGateway $appgateway
We are getting error Error during upload when uploading a file that is configured to save files to SharePoint Online. This is on Microsoft Dynamics AX 2012 R3.
We have document management enabled, we are currently saving files to a local folder on the AOS server but now want to save files to our online sharepoint library in O365.
I created the following folder AXTest in sharepoint, and granted the AX service account access to the sharepoint team.
I set Archive directory appropriately. I tried various veresions of the URL, which were all unsuccessful:
https://xxxxx.sharepoint.com/sites/Dev-Test/AXTest
https://xxxxx.sharepoint.com/sites/Dev-Test/AXTest/Forms
various document folders
All result in error when trying to upload a file that is local to the AOS server:
Through debugging, the error is raised here.
There is no exception stack so I don't know the exact reason why, but we tried various versions of the URL, we tried uploading a file locally, and we know the service account has access to the sharepoint site/team. Any other ideas?
Late but the "solution" is to make sure that a persistent cookie for SharePoint Online exists locally. I have been biting my head off to find a better solution, because it can get pretty complex to get that persistent cookie which makes it not suitable for end-users. To the point that my only solution might be to build a custom connector (or to urge for an upgrade...)
The key is to somehow force login.microsoftonline.com to prompt the user the question to remain signed-in. Only when you click Yes in that dialog is a persistent cookie created for SPO. Then the upload works fine, until the cookie expires / gets deleted.
These are the instructions for our users:
1. Make sure SPO / MS / Azure / ADFS related urls are not in the intranet zone in IE to prevent automatic login with windows credentials.
2. Sign out of SPO
3. Delete browser cookies
3. Restart IE
4. Go to SPO
5. You should be prompted to login with username and password
6. Then you will receive the question to Remain signed in. Click Yes.
Optional if this didnt work: Reset IE to default settings.
There's a KB included in CU13 for AX2012 R3 that seems to address the issue (mentions the vague "Error during upload" error). Haven't tested it myself, because i am trying to solve it in an AX2012 R2 CU9 environment.
I just ran across the same issue and what a NIGHTMARE!
For Windows Server 2012 R2, I wrote this little PowerShell script to help clear the cookies for all users.
We had users sign out of AX, sign off the terminal server(s), and then I ran the below script to just remove all user cookies. Next connection, they were in business.
$Remove = $false
Get-ChildItem -Path "C:\Users" -Directory | % {
$CachePath = Join-Path -Path $_.FullName -ChildPath "\AppData\Local\Microsoft\Windows\INetCache"
$CookiePath = Join-Path -Path $_.FullName -ChildPath "\AppData\Local\Microsoft\Windows\INetCookies"
if (Test-Path -Path $CookiePath)
{
Write-Host $_.FullName -ForegroundColor Green
if ($Remove) {
Get-ChildItem -Path $CookiePath -File -Recurse | Remove-Item -Force -ErrorAction Continue
Get-ChildItem -Path $CachePath -File -Recurse | Remove-Item -Force -ErrorAction Continue
} else {
Get-ChildItem -Path $CookiePath -File -Recurse | Format-Table -AutoSize
Get-ChildItem -Path $CachePath -File -Recurse | Format-Table -AutoSize
}
}
}
I've got a Windows container that's running in Azure that I'm trying to attach persistent storage to, however, I'm not able to find any documentation on how to do so.
Dockerfile:
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-20190910-windowsservercore-ltsc2016
SHELL ["powershell"]
EXPOSE 443
WORKDIR /CompanyAPP
COPY WebPackage.zip .
RUN Expand-Archive WebPackage.zip . ; `
Rename-Item ./CustomerWebConfigurator ./WebConfigurator; `
Rename-Item ./Customer ./WebRoot; `
Rename-Item ./CustomerWebService ./WebService; `
Rename-Item ./CustomerWCFService ./WCFService; `
rm WebPackage.zip
ARG BUILD
RUN Add-WindowsFeature Net-WCF-HTTP-Activation45;`
Install-PackageProvider -Name Nuget -Force;`
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted;`
Install-Module -Name AWSPowerShell;`
New-WebApplication -Site 'Default Web Site' -Name 'App' -PhysicalPath c:\CompanyAPP\WebRoot; `
New-WebApplication -Site 'Default Web Site' -Name 'AppWebService' -PhysicalPath c:\CompanyAPP\WebService; `
New-WebApplication -Site 'Default Web Site' -Name 'AppWCFService' -PhysicalPath c:\CompanyAPP\WCFService; `
New-WebApplication -Site 'Default Web Site' -Name 'AppWebConfigurator' -PhysicalPath c:\CompanyAPP\WebConfigurator; `
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters' -Name ServerPriorityTimeLimit -Value 0 -Type DWord;`
$cert = New-SelfSignedCertificate -Subject self; `
New-WebBinding -Protocol https -port 443 -name 'Default Web Site' -SSLFlags 0; `
$binding = Get-WebBinding -protocol https; `
$binding.AddSslCertificate($cert.Thumbprint, 'my');
RUN Set-WebConfiguration -PSPath 'IIS:\Sites\Default Web Site\App' -Filter '/system.web/customErrors' -Value #{mode='Off'};`
write-host 'got here!'
The storage is configured in an Azure Storage account, and using file storage, I'm attaching it in the configuration via path mappings, and am having no luck.
Hoping that someone can point me in a good direction to get this figured out.
I may be quite late to the party, but I stumbled upon this issue only today (mounting Azure File Volumes in a Windows Container still is not supported even a year later), and I found quite an easy workaround. I will share this here, because this question is one of the top results when searching for the error message.
You can mount your Azure File Volume via SMB. All you need is the UNC, a username and a password, which you can get from the properties of your Azure File Volume
So I created a small startup.cmd
#echo off
net use z: %MNTUNC% %MNTPASS% /user:%MNTUSER%
"c:\program files\myapp\myapp.exe"
and defined that startup.cmd as the entrypoint in the dockerfile
....
COPY ["startup.cmd", "c:/startup.cmd"]
ENTRYPOINT ["c:/startup.cmd"]
Pitfall: Be aware, that a drive mapped with net use (or New-PSDrive if you prefer PowerShell) is only visible to the user account under which the command was executed, so be sure to mount the drive with the same user, which is used to execute the service.
You can set the values for the environment variables during deployment like described here:
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-environment-variables
For instance, when using a YAML file for deployment, you can set the environment variables as follows. Using secureValue makes the value of the environment variable accessible only from within the container and the values won't be shown for instance in the properties of the container on the azure portal.
....
containers:
- name: mycontainer
properties:
environmentVariables:
- name: 'MNTUNC'
secureValue: '\\myaccountname.file.core.windows.net\myvolume'
- name: 'MNTPASS'
secureValue: 'mysupersecretpassword'
- name: 'MNTUSER'
secureValue: 'Azure\myaccountname'
If you use the Azure Container Instance to deploy for Windows container, then the Azure File storage does not support the persistent volume., it's currently restricted to Linux containers. You can get more details about the note here:
Mounting an Azure Files share is currently restricted to Linux
containers.
Update:
With the message that the provided in the comment, you use the web app for the container with the Windows image. In this situation, it supports to mount the Azure File Share to the Windows Container. You can follow the steps in Configure Azure Files in a Windows Container on App Service.
Does anybody know how to resolve this issue?
Replicate when you type the following command in PowerShell.
dir iis:\sslbindings
I have comes across this page on Microsoft TechNet which doesn't address the problem.
Edit
When invoking the command I get the error
failed to enumerate SSL bindings
Apparently due to a corrupted registry?
In my case, I've got the error when I had both SslCertStoreName and DefaultSslCtlStoreName in the registry. I deleted DefaultSslCtlStoreName and the error is gone for a while. For some reason, DefaultSslCtlStoreName was created in the registry again, and I've got the error again. So I wrote a simple powershell script that deletes it.
This is the part from my build script.
function CleanupSslBindings()
{
$sslBindingsPath = 'hklm:\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo\'
$registryItems = Get-ChildItem -Path $sslBindingsPath |
Where-Object -FilterScript { ($_.Property -eq 'DefaultSslCtlStoreName')}
If ($registryItems.Count -gt 0) {
ForEach ($item in $registryItems) {
$item | Remove-ItemProperty -Name DefaultSslCtlStoreName
Write-Host "Deleted DefaultSslCtlStoreName in " $item.Name
}
} Else {
Write-Host "No DefaultSslCtlStoreName found. The SSL Bindings registry is clean."
}
}
In my case, I had built WCF services hosted as windows services. When I did this, I apparently didn't know (and still don't) how to assign things like appid's (noticeable when you netsh http show sslcert), and other items that crop up... including an item related to this error.
Essentially, I read the same page the OP did: https://social.technet.microsoft.com/Forums/windowsserver/en-US/87b1252d-a6a0-4251-bbb6-38e104a8c07a/enumerating-iissslbindings-gives-failure-on-one-machine-works-on-another?forum=winserverpowershell
...and using a regedit, went to the key: HKLM\System\Currentcontrolset\services\http\parameters\sslbindinginfo
I saw all the same entries I see when I do the netsh command above. However, my wcf services are listed first, followed by my IIS sites. None of my wcf services had the SSLCertStoreName key (only the IIS sites had the key). Following the article's explanation that the first entry needs to have that registry key (this is a bug in my opinion), I performed the following PowerShell commands:
Try
{
Get-ChildItem IIS:\SslBindings
}
Catch
{
$1stentry = Get-ChildItem HKLM:\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo | Select-Object -First 1
$1stentry | New-ItemProperty -Name "SslCertStoreName" -Value "MY"
Get-ChildItem IIS:\SslBindings
}
This code works for me. And that article helped get me here and understand that my root cause of this 234 error code, is an assumed self-inflicted wound by not installing my WCF services correctly. YMMV. Hope this helps.
Apologies for the delay but I resolved the issue with the following script (see below). For some bizarre reason (I don't know why) something was adding two entries in my registry and after removing these the problem went away. I figured this out as I compared my registry to another machine who wasn't having this problem and found the culprit.
Remove-ItemProperty -Path "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo\" -Name "[::1]:26143" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\SslBindingInfo" -Name "127.0.0.1:26143" -ErrorAction SilentlyContinue
echo "Done."
#Bewc I reckon you are onto something there although I think it affects more than just WCF services. We have a powershell script that builds and deploys a website onto a machine (sounds crazy I know). Who or what creates these entries I have no idea but perhaps some background process in IIS?
I am trying to add an MSMQ binding for my IIS Web Site, correct binding should look like this:
So I am executing following line in PowerShell:
New-WebBinding -Name "My Site" -Protocol net.msmq -HostHeader "localhost"
and it creates the following binding:
prefixing it with *:80:, so my MSMQ messages don't get picked up by WCF service. Maybe I am doing it wrong? How to create a binding with Binding Information set to just "localhost" using this PowerShell comandlet?
Commandlet codumentaiton can be found here.
Looking at the decompiled code of the cmdlet, looks like it adding the IPAddress and Port information in the binding and there is no workaround to it.
Relevant sections from the code:
private string ipAddress = "*";
...
builder.Append(this.ipAddress);
...
builder.Append(":" + this.sitePort.ToString(CultureInfo.InvariantCulture) + ":");
But you can do what the cmdlet actually does ( below code from cmdlet):
new-itemproperty -path "IIS:\sites\test" -name bindings -value #{protocol="net.msmq"; bindingInformation="localhost"}
Give this a try:
New-ItemProperty "IIS:\sites\NameOfYourSite" -name bindings -value #{protocol="net.msmq";bindingInformation="localhost"}
If your are running PowerShell (Core), a.k.a PowerShell >v7.1.x, you will find yourself in trouble because...
WARNING: Module WebAdministration is loaded in Windows PowerShell using WinPSCompatSession remoting session;
please note that all input and output of commands from this module will be deserialized objects.
If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.
The IIS provider isn't available via remoting session.
The easiest trick is to redirect string via pipeline to Windows PowerShell.
"Import-Module WebAdministration;New-ItemProperty -Path `"IIS:\Sites\$($configuration.Website.Name)`" -Name Bindings -value #{protocol = `"net.msmq`"; bindingInformation = `"localhost`" }" | PowerShell
In this example, the website name is read from the configuration JSON. You can replace it by a hard-coded site name.