I'm trying to create a VM using PowerShell in Windows Azure Pack.
I've downloaded the subscription, and Get-WAPackVM returns the VM's already created.
I've tried running these two scripts:
$OSDisk = Get-WAPackVMOSDisk -Name "W2012R2 Template_disk_1"
$SizeProfile = Get-WAPackVMSizeProfile -Name "Template"
New-WAPackVM -Name "ContosoV073" -OSDisk $OSDisk -VMSizeProfile $SizeProfile
and
$Credentials = Get-Credential
$Template = Get-WAPackVMTemplate -Name "Template 1"
New-WAPackVM -Name "VirShits7" -Template $Template -VMCredential $Credentials -Windows
Both returns the same error:
New-WAPackVM : The remote server returned an error: (400) Bad Request.
All the Get cmdlets return values, and seem to be correct.
Anyone know how I get this to work?
You may reference the page:
https://msdn.microsoft.com/en-us/library/jj643289.aspx
The page say:
The key properties that you must set on the virtual machine object that is used with the Service Provider Foundation service are as follows: CloudId, StampId, VMTemplateId ,Name.
You may need to assign CloudId and StampId.
I did it by RESTApi and it works.
Related
We are trying to create list of applications in a particular site,
For this we have a csv which contains required information for site creation. Below is the format:
Below is the script which we are using to create application in IIS:
foreach($app in $apps){
$appname = $app.path.TrimStart("/")
New-WebApplication -Name $appname -Site $app.Site -PhysicalPath $app.PhysicalPath -ApplicationPool $app.applicationPool -Verbose
}
Problem is application whose code is stored on some network path like \\network\Webapps\appname are giving below error:
New-WebApplication : A parameter cannot be found that matches parameter name 'physicalPath'.
whereas application folder located on same server are being created without any issue,
Have also done test-path \\network\webapps\appname it results in true
What is the issue and how to rectify it?
Issue got resolved, I didn't got what was the exact reason behind that, Have updated my script, basically have assigned values to specific variable than was able to create application.
Updated Script
foreach($app in $apps){
$appname = $app.path.TrimStart("/")
$appSite = $app.Site
$appPath = $app.PhysicalPath
$appPool = $app.applicationPool
New-WebApplication -Name $appname -Site $appSite -PhysicalPath $appPath -ApplicationPool $appPool -Verbose
}
Thanks
First of all, you have to make sure that powershell has permission to access the server corresponding to the network path when creating the site.
When using powershell to create a site, if the physical path of the site is a file in the local disk, you can use New-WebApplication, if it is a UNC path, you should use New-Item.
Under normal circumstances, the UNC path will not be used as the physical path of the main site, but will be added as a virtual directory. Because the domain name of the main site points to the local machine and the UNC points to the remote IP address, the two will conflict because a server error occurred when I created the site through IIS Manager.
$siteName = 'Default Web Site'
$virtualDirectoryName = 'Test'
$physicalPath = '\\UNC-path'
## Init
$virtualDirectoryPath = "IIS:\Sites\$siteName\$virtualDirectoryName"
## Create Virtual Directory where physicalpath is an UNC-path (New-WebVirtualDirectory
wont do)
New-Item $virtualDirectoryPath -type VirtualDirectory -physicalPath $physicalPath
Any chance it's this? That error sounds like it's an issue with the cmdlet and not the data you're feeding it.
https://social.msdn.microsoft.com/Forums/en-US/3e0cb076-6ad4-4b03-bb59-c912174266b0/container-with-iis-cant-create-application-using-powershell-physicalpath-parameter-not-found?forum=windowscontainers
specifically:
You need to import the WebAdministration module. If you're in the container through docker exec simply use:
Import-Module WebAdministration
I was connecting Exchange Online using a PowerShell window that is opened with system access. I used PSExec on an elevated Command Prompt to open the System access PowerShell. Below is the command.
PSExec -i -s PowerShell
On the PowerShell, I imported the latest Exchange Online Management PowerShell module version 2.0.3. I use the app-based authentication described here: https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#setup-app-only-authentication.
There is one more website that shows how to connect with app-based authentication: https://o365reports.com/2020/07/04/modern-auth-and-unattended-scripts-in-exchange-online-powershell-v2.
Below are the commands used to connect to Exchange Online.
Import-Module .\ExchangeOnlineManagement
$sessopt = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck -ProxyAccessType IEConfig
$certkey = ConvertTo-SecureString "<EnterCertificateKeyHere>" -AsPlainText -Force
Connect-ExchangeOnline -CertificateFilePath "pfx Certificate Path" -AppId <EnterAppIdHere> -Organization "domain.onmicrosoft.com" -CertificatePassword $certkey -PSSessionOption $sessopt -verbose
When running the above, it returns Object Reference error. I got excited and went on to find what the error is by decompiling the DLL files and found that inside the 'ExoPowershellGalleryModule.dll -> NewExoPSSession.cs' of the Exchange module, the 'GetAccessToken' function which is called around line:308 causes this error. Any idea what makes the Object reference not set to an instance of an object. System.Management.Automation.RemoteException: Object reference not set to an instance of an object. error. Was the proxy not taken from IE?
I've set the proxy settings in IE using the below Powershell command-lets in system PowerShell.
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -name ProxyServer -Value "ProxyServerAddress"
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -name ProxyEnable -Value 1
Any help to resolve this is appreciated.
If your using
PSExec -i -s PowerShell
Then the proxy information your entering for the user will have no effect because the local system account will have its own profile information. Also if the proxy needs authentication you also won't be presenting any Network credentials.
If you really want to run under the system account you could try using netsh to configure the proxy https://learn.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet but if you proxy need authentication this won't work.
I'm trying to execute below command in a PowerShell Workflow Runbook. I'm getting the error "cannot index into a null array.", which is not true as the same script which ran perfectly on my local machine is not executing while in the Azure portal as a PowerShell Workflow Runbook.
Can anyone please look into this?
$webApp = Get-AzureRMWebAppSlot -ResourceGroupName $ResourceGroupName -Name $WebSiteName -Slot $WebSiteSlot
$webApp
"Printing Website ConncectionString"
$webApp.SiteConfig.ConnectionStrings.ConnectionString[0]
Some types do not serialize/deserialize correctly, and in PowerShell Workflow that is a problem because PowerShell Workflow relies on object serialization/deserialization (that's how PSWF is able to checkpoint, suspend, and resume -- it converts all objects to a string form when checkpointing/suspending, and restores back to full objects from those strings when resuming).
It would appear Get-AzureRMWebAppSlot's output object is one of those types that does not serialize/deserialize correctly. From your screenshot I can see that the SiteConfig property of $webApp is a string containing Microsoft.Azure.Management.WebSites.Model.SiteConfig rather than an object as you're expecting. Clearly, the object is not deserializing correctly back to its original form, where SiteConfig is a complex object.
The way to work around this is to only interact with the object in PowerShell script context, rather than workflow context. For example:
workflow foo {
$ResourceGroupName = "RG"
$WebSiteName = "WS"
$WebSiteSlot = "Slot"
$ConnectionString = InlineScript {
$webApp = Get-AzureRMWebAppSlot -ResourceGroupName $using:ResourceGroupName -Name $using:WebSiteName -Slot $using:WebSiteSlot
$webApp.SiteConfig.ConnectionStrings.ConnectionString[0]
}
"Printing Website ConnectionString"
$ConnectionString
}
I have registered a PowerShell Configuration for use but am running into some difficulties. The desire was to implement a configuration that would allow a service account to remote into a server and restart it without allowing it the ability to perform anything else, naturally JEA seemed like the best fit. I registered the configuration with the following:
#Create Role Capability file
$ServerRestartRole2012 = #{
Path = "$env:ProgramFiles\WindowsPowerShell\Modules\JEAServerRestart\RoleCapabilities\ServerRestarter.psrc"
Author = "xx"
Company = "xx"
VisibleCmdlets = 'Restart-Computer'
ModulesToImport = 'Microsoft.PowerShell.Management'
}
New-PSRoleCapabilityFile #ServerRestartRole2012
#Create JEA Config
$ServerRestartConfig2012 = #{
Path = "$env:ProgramData\JEA\JEAServerRestart.pssc"
Author = "xx"
Description = "Allows for service account to reboot servers for Server Management Application"
SessionType = "RestrictedRemoteServer"
TranscriptDirectory = "$env:windir\Logs"
RunAsVirtualAccount = $true
RoleDefinitions = #{'xx\D7_APP_ServerRestart' = #{ RoleCapabilities = 'ServerRestarter'}}
}
New-PSSessionConfigurationFile #ServerRestartConfig2012
Register-PSSessionConfiguration -Name ServerRestarters -Path "$env:ProgramData\JEA\JEAServerRestart.pssc"
Restart-Service -Name WinRM
The registration is successful and I can enter the session with an account contained in the 'D7_APP_ServerRestart' group. Using Get-Command results in what I would expect, but when running Restart-Computer the message that is returned explains Privilege not held Am I missing part of the setup process?
The server with the registered EndPoint is a 2012R2
resulting output
As it turns out, after playing around a bit I found a resolution. Specifying a different protocol for the restart-computer cmdlet to use allowed it to restart the remote server.
restart-computer -force fails with Permission not held
restart-computer -protocol WSMan -force Performed a successful remote reboot
I'm sure there is a valid reason for this, I just haven't been able to find the documentation to support it.
Hopefully this will prevent future headaches for new JEA users.
For a website my team are currently working on we're trying to write some PowerShell automation to temporarily override a connection string which is otherwise usually in Web.config, and then at a later point delete it.
However, using both the PowerShell cmdlets and the Azure REST APIs, we don't seem to be able to ever reset the connection strings set to be empty. Whenever we try to delete it either the command says it succeeds but doesn't delete it, or the requests is rejected as invalid.
It's possible to delete all the connection strings using the Management Portal, so what are we missing that means we can't do it programmatically?
Here's an example PowerShell command we're using that isn't doing what we want:
$website = Get-AzureWebsite $websiteName -slot $websiteSlot
$connectionStrings = $website.ConnectionStrings
$result = $connectionStrings.Remove(($connectionStrings | Where-Object {$_.Name -eq $connectionStringName}))
Set-AzureWebsite $websiteName -slot $websiteSlot -ConnectionStrings $connectionStrings
I know this is really late.
I have faced the same situation.We are able to update the App settings but not the connection strings.I found the solution.Since it doesn't have an answer, I thought it would be good to update it..
As per the git-hub source, the hash-table(nested) needs to be in the format of
#{ KeyName = #{ Type = "MySql"; Value = "MySql Connection string"}};
after which I ran the code to update the App, it worked. Below is the whole code
$list = #{ ConnectionString1 = #{ Type = "MySql"; Value = "MySql Connection string"}};
set-AzureRMWebAppSlot -ResourceGroupName "resourceGroup" -Name "devTest" -ConnectionStrings $list -slot "production"