I currently have some problems with the azure commandline in a Web App.
I get following error:
[10/28/2015 20:22:33 > 37539e: ERR ] New-Item : The Win32 internal error "The handle is invalid" 0x6 occurred while
[10/28/2015 20:22:33 > 37539e: ERR ] getting the console mode. Contact Microsoft Customer Support Services.
This occurred on New-Item and Remove-Item. It happens in the Kudo Powershell console and using Powershell-Scripts ina WebJob.
Instead of New-Item file I have successfully used echo 3 >> file. This worked without problems. The only thing I found was that there is a problem using Invoke-WebRequst and that it will be fixed using
$ProgressPreference="SilentlyContinue"
Unfortunately this didn't helped.
Did someone experienced something similar?
Thanks in advance.
Some cmdlets may attempt to read the console mode of the standard input or standard output streams if it is attached to the console. This can be avoided by setting them explicitly to null.
# Prevent the progress meter from trying to access the console mode
$ProgressPreference = "SilentlyContinue"
# Set the input and output streams to $null
$null | Invoke-WebRequest -UseBasicParsing http://www.example.com/ > $null
For me, setting $ProgressPreference="SilentlyContinue" does solve the issue.
(Using the PowerShell Console of the Kudu site of an Azure App Service.)
$null | (…) > $null also prevents the error, but that also suppresses the return value, which I don't want.
Background: Apparently Invoke-WebRequest tries to display a progress bar, which Kudu's PowerShell does not support. (source)
The error seems to be related to the protection of our proprietary sandbox for Web Apps. However, one possibility is to use Windows Containers on App Service.
Here you can follow the quickstart to run a Windows Container in App Service:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-get-started-windows-container
Related
I often hit the dreaded Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again error when using Invoke-WebRequest.
Various pages point out this issue and the use of the UseBasicParsing switch, but it is an annoyance to have to put that into every command.
Is there a way that I can declare, at the start of a script, some commands to force Internet Explorer to silently perform its first-launch configuration and accept all defaults so that the UseBasicParsing switch is no longer required?
This answer on the page you provided actually suggests setting the registry value with PowerShell that will disable the first run wizard for Internet Explorer and allow you to use Invoke-WebRequest without -UseBasicParsing parameter.
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Internet Explorer\Main" -Name "DisableFirstRunCustomize" -Value 2
I have an API which returns a file as byte[].
I am trying to download this file onto a local machine using PowerShell (needs to be PowerShell for other automation reasons).
I am using WriteAllBytes, however, it throws error with files which are larger than 100MB (I think, threshold might be different).
Are there any other ways to download these files and convert byte[] into an actual file?
Here is what I have at the moment:
$fileInfo = New-Object ($namespace + ".fileInfoRequest")
$fileInfo.Filename = "$($File)"
$fileInfo.Hash = "e0d123e5f316bef78bfdf5a008837577" #random hash so ignore this.
$FileDetails = $WebService.GetFileInfo($fileInfo)
if ($FileDetails.Exists -eq "True") {
[IO.File]::WriteAllBytes("$($InstallPath)\$($File)", $WebService.GetFileData($FileDetails))
} else {
Write-Host -ForegroundColor Red "File $($File.FileName) could not be found in the system"
}
$WebService.GetFileData($FileDetails) returns the file data in byte[] so this is the one that I need to manipulate somehow.
I faced the same message right this morning.
Weirdly in my case the problem was triggered only when using a remote powershell session, so I can see affinity with API which can be passing trough network as well.
It happened, in my case, that the same command from a "standard" powershell session opened directly on the server console was not raising the error.
I was able to avoid it by using the following on an admin powershell session on the server console:
set-item wsman:localhost\Shell\MaxMemoryPerShellMB 2048
After that all the remote powershell session stop to give OutOfmemory.
I am attempting to get a script working that does not use invoke-webrequest. The problem I am having is that when I run the script a popup prompt occurs, the popup consists of the following message;
"Windows Security Warning
To allow this website to provide information personalized for you, will you allow it to put a small file (called a cookie) on your computer?"
with yes no response from user
The code I am executing is the following:
$ParsedHTML = New-Object -com "HTMLFILE"
$webresponse = New-Object System.Net.WebClient
$webresponse.Headers.Add("Cookie", $CookieContainer.GetCookieHeader($url))
$result = $webresponse.DownloadString($url)
$ParsedHTML.IHTMLDocument2_write($webresponse)
$ParsedHTML.body.innerText
The main problem with this code is that the $url I am using part of the weblink checks to see if cookies are enabled and this code causes a returned value of disabled.
My question, is there a way to handle the cookie request without changing the output response from the test url site.
Note: This script will be automating a process over hundreds of remote computers and thus having an unhandled popup will just prevent the script from running.
I found the answer in another SO question Using Invoke-Webrequest in PowerShell 3.0 spawns a Windows Security Warning
add the parameter -UseBasicParsing
Technet https://technet.microsoft.com/en-us/library/hh849901.aspx notes that the parameter stops the DOM processing. and has the caveat "This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system."
So, you mileage may vary.
So I am trying to use Powershell to start a windows service. I have the service installed just fine, but when I call Start-Service -Name $name I am recieving the following error.
Start-Service : Service 'IncidentManagementService (IncidentManagementService)' cannot be started due to the following error: Cannot start service IncidentManagementService on computer '.'.
I have powershell running as an Administrator and I also tried going under the properties of the .exe file and checking "run as admin" to no avail.
If anyone could give me a clear reason as to why the service is not starting it would be much appreciated.
In my case the service is disabled... so is the reason I am getting that error.
thanks for taking the time to try any help me out!
As the title suggests I cannot get the Merge-SPLogFile cmdlet to return me any results!
I find hunting down error messages in SharePoint logs a very time consuming and laborious process- Being relatively new to PowerShell I only recently stumbled across the cmdlet. Knowing how much time this could save me I was excited to implement it.
I started with the following code:
Add-PSSnapin Microsoft.SharePoint.Powershell
$correlationId = "C826869C-4A8E-10E2-6C5E-58A1C87EB651"
Merge-SPLogFile –Path “C:\Users\Administrator\Desktop\SPLog.log” –Correlation $correlationId -Overwrite
This gives me the warning- "WARNING: Cmdlet did not return any records in the log file. Check your time range or filters."
Naturally I typed the error into my search engine and it seems other people have had the same problems when the -Correlation argument isn't in upper case. I tried both uppercase and lowercase but to no avail. I was able to manually find the GUID in the logs so I know it exists.
When I ran out of luck with this technique I thought I would try filtering using different arguments (by time):
Add-PSSnapin Microsoft.SharePoint.Powershell
[int] $HowFarBack = 15
[int] $howFarBackInMinutes = (-1) * $HowFarBack
[datetime] $startDateTime = [System.DateTime]::Now.AddMinutes($howFarBackInMinutes)
write-host $startDateTime
Merge-SPLogFile -Path 'C:\Users\Administrator\Desktop\SPLog.log' -Overwrite -StartTime $startDateTime
I get exactly the same error. To rule out my arguments being incorrect I tried not giving it a filter at all:
Add-PSSnapin Microsoft.SharePoint.Powershell
Merge-SPLogFile -Path 'C:\Users\Administrator\Desktop\SPLog.log' -Overwrite
I still get- "WARNING: Cmdlet did not return any records in the log file. Check your time range or filters." The logs are all there and in the default "LOG" folder within the 15 hive. I haven't changed any logging settings away from the defaults.
I am running on SharePoint 2013 Foundation.
What am I doing wrong?
The problem in my case was that there was no diagnostic logging activated for my SharePoint Farm.
How to enable diagnostic logging
Go to your Central Administration (usually http://YOUR_SHAREPOINT:10000/) (there is also a shortcut in your start menu on the server you installed the SharePoint at)
Go to "Monitoring"
Under "Reporting" click "Configure diagnostic logging"
Select the categories that you want to merge in case of an Error. I just selected All Categories here. Then click the "Ok" button at the bottom of the page.
(5. Reproduce the error and use the SP Shell again to Merge the Log Files)