What is the difference between WebCommitDelay and IISCommitDelay?
MS docs says the same for both:
Instructs the IIS configuration system to delay the commitment of changes.
So what should I prefer and why? It looks like they have some differences indeed, because if I use WebCommitDelay, I can't use New-WebApplication ... -Force if the same application is exists, but I can do this if I use IISCommitDelay.
As far as I know, the IISAdministration PowerShell module which was a new way to manage IIS.
This module included numerous improvements over the existing WebAdministration cmdlets.
So the IISCommitDelay is the new method which is used to management the IIS.
Detials, you could refer to this article.
Related
I need the ability to have users run a script that requires the ActiveDirectory module. I copied over the following:
"C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ActiveDirectory", "Microsoft.ActiveDirectory.Management.resources.dll", "Microsoft.ActiveDirectory.Management.dll".
The script runs two Get-ADUser commands, 1 without the -Server parameter and the other with. The issue is that the former is working but the latter is not.
Is there another module that I need to copy over?
I don't like the idea of installing administrative tools for non-admins. Even if you could get away with copying files and not doing the full-blown RSAT installation. Not the least of reasons is you are dramatically increasing the attack surface for malicious actors. The better solution is (Just Enough Administration) JEA, or a philosophically similar approach.
JEA / Contrained endpoints can get complicated, but a summary of what you can do looks something like this:
New-PSSessionConfigurationFile -Path 'C:\PSSessionConfigs\DemoPSEndpointConfig.pssc' -ModulesToImport ActiveDirectory -VisibleCmdlets "Get-ADUser"
Register-PSSessionConfiguration -Path 'C:\PSSessionConfigs\DemoPSEndpointConfig.pssc' -ShowSecurityDescriptorUI -Name DemoPSEndPoint
Run these commands on a system that has the ActiveDirectory module (likely the whole RSAT component) installed, it doesn't need to be a Domain Controller. It will create a new PowerShell remoting endpoint configuration that exposes only the commands you wish. The Register-PSSessionConfiguration command will display a security dialog where you can permission which users you want to allow to connect, you want to grant them read & execute permission. Once that's done, you can get the results with an Invoke-Command command like this:
Invoke-Command -ComputerName <ServerName> -ConfigurationName DemoPSEndPoint -ScriptBlock { Get-ADUser <UserName> }
You can add the -Server parameter in the command without issue. You can expand the cmdlets you are allowing in the New-PSSessionConfiguration command.
Again this is very much a summary of a more complex topic but should be enough to get what you want.
Personally, I don't use configuration files as much as I use startup scripts. I think the latter is more flexible. You can get some information about that here. If you really want to dig into this there are references at the end of the article including a link to the PowerShell JEA documentation. There's also a link to some of the MVP articles I used to develop my own endpoints.
The ActiveDirectory module is dependent on the RSAT (remote server administration tool). This is avalible to install/activate through powershell: https://mikefrobbins.com/2018/10/03/use-powershell-to-install-the-remote-server-administration-tools-rsat-on-windows-10-version-1809/
With this installed you automatically also get the Activedirectory module installed.
I am trying to understand difference between two modules, Azure AD and MS Online modules. Currently on my windows 10 machine I can use get-azureaccount cmdlet that returns my current Azure account. And there is bunch of cmdlets that I can use right now. Then why I need MS Online module.
Please help me to understand the purpose of these two modules.
Get-AzureAccount / Get-AzureRMAccount is a part of the "Azure" module.
When working with Azure AD (Active directory commands; not a part of the built-in modules) in Azure you will need the MSOnline module - which also happens to be the same module as for working with Office365. Usually MSOnline is referred to as the Azure Active Directory module for Windows Powershell.
Eg. if you install the Azure Active Directory module from example here: Microsoft - Active Directory Module for Windows Powershell 64-bit - you will get the MSOnline module installed on your machine. You can actually inspect / unpack the msi installer and you will see that the package here is Microsoft.Online.Administration.MSOnline.psd1
In order to work with Azure AD from Powershell, you'll then need to import this module (which contains a set of functions to work with Azure AD).
To list commands within this module after installing the module you can do the following:
Get-Command -Module MSOnline
Hope this clears the confusion.
Connect-Azure: allows user to manage Active Directory objects only, [where directory is hosted in Azure].
Connect-Msoline: apart from managing Active Directory allows more administrative tasks such as Domain management, configure single sign-on etc.
Hope this clarifies your doubt.
Reference
https://learn.microsoft.com/en-us/powershell/module/azuread/connect-azuread?view=azureadps-2.0
https://learn.microsoft.com/en-us/powershell/azure/active-directory/install-msonlinev1?view=azureadps-1.0
In my opinion, it's a matter of selecting the best tool for the job. And the way to select the tool is based on
What you're going to do with it &
what does the tool do
If we take a look at the properties offered by get-msoluser
(get-msoluser)[0] | gm -MemberType Properties
we get a slightly different set than we do when we query get-azureaduser with
(get-azureaduser)[0] | gm -MemberType Properties
and the same can be said when we review the methods available to the objects:
(get-azureaduser)[0] | gm -MemberType Method
or
(get-msoluser)[0] | gm -MemberType Method
Now, since the general idea is to get things done quickly and simply. It then becomes clear to use the one that directly supports what you intend to achieve. And if they both cover the job then I would base my decision of which additional cmdlets in the module support the task I want to achieve without needing to load a whole stack of modules.
So I hope this helps find the right tool for the job.
Have fun,
Porky
How can I modify various settings inside either a new or exisitng App Pool using Powershell?
I am interesting in some of the "Advanced" settings such as Enable 32-Bit Applications, Managed Pipeline Mode, Process Model Identity, etc. Any ideas on how I can do this? I tried using the xWebAdministration module but that seems to have very basic settings.
Yes, a custom DSC resource is the only way to do this with DSC. If you are able to use PowerShell scripting without DSC, you can use the WebAdministration module module to create the pool, and then modify it from there.
$appPoolName = "MyAppPool"
New-WebAppPool -Name $appPoolName
$appPool = Get-Item "IIS:\AppPools\$appPoolName"
$appPool.processModel.identityType = 3
$appPool.processModel.username = "someUser"
$appPool.processModel.password = "somePassword"
$appPool.managedRuntimeVersion = "v4.0"
$appPool.managedPipeLineMode = "Integrated"
Update 1/31/2015
In the PowerShell.org community DSC modules, someone made a cWebAdministration pull request that apparently includes "37 app pool config options". Might be a great solution.
You need to write your own custom DSC resource for doing that.
This is a good starting point.
However, I recommend that you take a look at Script resource to build the logic required for all three functions in a DSC resource and experiment before writing a resource.
I have this large application that I am using Windows RM 3.0 to deploy Databases, SSIS packages, and other things to multiple different servers and it is working just fine. It was requested that branding changes to a Business Intelligence SharePoint site be added to this process as well. So I create a custom build script to do so, and set Win RM to run this command from PowerShell on Sharepoint server
Install-SPSolution –Identity Payload\SharepointDeploy.wsp –WebApplication http://localhost/ -GACDeployment
when I run that, I get the following error
Install-SPSolution : Microsoft SharePoint is not supported with version 4.0.30319.18444 of the Microsoft .Net Runtime.
Reading around, it seems its a PowerShell 3.0 issue and when running in 2.0 it works fine. However, my existing process requires PowerShell 3.0 to work properly. Is there anyway to get this working with 3.0? Or can I spin up a 2.0 instance using an Invoke-Command or something? I can provide more details if needed.
You can build a custom endpoint which will run the required version of PowerShell. That way you won't have to mess with the default endpoint which you probably want to keep with its defaults
This would require you to connect to the new endpoint with something like
new-pssession -computername "SharePoint01" -configurationName "psv2".
You build and endpoint with the following cmdlet:
New-PSSessionConfigurationFile -Path "psv2session.pssc"
And then register an endpoint using that config with this cmdlet:
Register-PSSessionConfiguration -Name psv2 -Path psv2session.pssc –ShowSecurityDescriptorUI
It's fairly easy to do, and this link provides a good introduction to the setup:
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file.aspx (although the blog deals with constrained endpoints, the teqnique is essentially the same for what you need to do)
I was facing the same issue with console application, I decreased the framework version from 4.5 to 3.5 from the project properties page and I works perfect!
After reading several other blog posts and articles (references found below) there appear to be several ways to run PowerShell on .NET 4.0 but few are sufficient for our purposes. Due to how we deploy our software we cannot update the registry or change add an application. This leaves us with two options, create our own shell by using ConsoleShell or override PSHost. We would like to be able to use the first option, ConsoleShell, due to it's simplicity but would like to know what issues we may encounter and whether doing so is recommended.
Reference
Based on other questions I have seen that you can use the following methods to run PowerShell as .NET 4.0. None of these methods appear to be officially sanction by Microsoft but the first shown below is included as a work around in this Microsoft connect issue.
The options to run PowerShell in .NET 4.0 appear to include:
Update the app.config to include .NET 4.0 as supported
Add a registry setting to switch the version
Use ConsoleShell to host your own PowerShell Console
Implement your own PowerShell host, PSHost , as done by PoshConsole or Nuget
As far as it is not officially approved (to my knowledge), then nobody can approve it but you. If your scenario works and passes reasonable tests, approve and use it.
I use PowerShell on .NET 4.0 but with the option 4, and used to use the option 1, too (I do not like the option 2, personally). Thus, I approved it, production or not, I use it a lot and it works. I still use PowerShell on .NET 2.0 for two reasons: 1) PowerShell.exe starts faster (especially x64); 2) to be sure that part of my PowerShell development is compatible with .NET 2.
Another thought. If something does not work properly in PowerShell on .NET 2.0 (there are some issues, indeed, see Connect) then the fact "it is approved for production" itself does not help much. One has to overcome existing issues, .NET 2 or .NET 4 does not matter.
P.S. I should have mentioned that I tried the option 3 as well. I did not find use cases suitable for using it in my scenarios. But I did not find any issues in using ConsoleShell either.
P.P.S Yet another option. Make a copy of PowerShell.exe, rename it into MyConsoleShell.exe, use it together with MyConsoleShell.exe.config configured for .NET 4. As far as you are going to use a separate application anyway, then why not to consider this?
I'm a bit of a powershell N00b, but I threw this together as a way of forcing an arbitrary script to use .NET 4.0 in my script:
# Place this at the top of your script, and it will run as a .NET 4 ps script.
# #############################################################################
if ($PSVersionTable.CLRVersion.Major -lt 4) { try {
$cfgPath = $Env:TEMP | Join-Path -ChildPath ([Guid]::NewGuid())
mkdir $cfgPath | Out-Null
"<configuration><startup useLegacyV2RuntimeActivationPolicy='true'><supportedRuntime version='v4.0'/></startup></configuration>" | Set-Content -Path $cfgPath\powershell.exe.activation_config -Encoding UTF8
$darkMagic = 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath'
$old = [Environment]::GetEnvironmentVariable($darkMagic)
[Environment]::SetEnvironmentVariable($darkMagic, $cfgPath)
& powershell.exe $MyInvocation.MyCommand.Definition $args
} finally {
[Environment]::SetEnvironmentVariable($darkMagic, $old)
$cfgPath | Remove-Item -Recurse
return
}}
# ##############################################################################
# My script starts here:
echo "Your arguments are: $args "
echo "The CLR Major Version is : $($PSVersionTable.CLRVersion.Major)"
It places a check in the beginning of the script, and if it's not .NET 4.0 it creates a configuration file, sets an environment variable and re-runs the powershell script so that it runs under .NET 4.0.
it does incur a bit of a startup time penalty of about a second or so on my pc, but at least it works :)