I have a script that tests whether one of our websites is working properly.
Test 1: It checks the HTTP status. (no problem here)
Test 2: It checks whether user authorization is working because we have had issues with this in the past.
Then it waits one hour and runs both tests again.
The overall structure of the script is as follows (pseudocode):
while (1 -eq 1) {
test1
if ($result -eq "pass") {
test2
}
start-sleep -seconds 3600
}
Test 2 is where the problem occurs. How this test works is: navigate to the login page, enter credentials, click login button. Check URL, as successful login leads to a different URL from the login page. This works fine, except on (seemingly random) loops it cannot access the elements of the page: the username and passwords fields and the login button. The exceptions that get thrown vary depending on how I change the code around to try to fix the problem.
Some error messages I've gotten include:
System.Runtime.InteropServices.COMException The RPC server is
unavailable. (Exception from HRESULT: 0x800706BA)
System.Runtime.InteropServices.COMException
The property 'value' cannot be found on this object. Verify that the property exists and
can be set.
System.Runtime.InteropServices.COMException
OperationStopped: (:) [], COMException
HResult: -2147352319
No such interface supported
System.Runtime.InteropServices.COMException
OperationStopped: (:) [], COMException
HResult: -2147352319
This command is not supported.
The offending code is anything that tries to access a page element with getElementByID, for example:
$ie.Document.getElementByID("username").value = $userame
Again, the weird thing is that the code runs fine for hours and hours... but then, usually in the middle of night, it randomly becomes unable to access the page elements.
Following is the full code of Test 2 in case that helps:
$ie = New-Object -ComObject "internetExplorer.Application"
#$ie.Visible = $true
$ie.navigate2($loginPage)
while ($ie.busy -eq $true) {start-sleep -seconds 1}
$ie.Document.getElementByID("username").value = $username
$ie.Document.getElementByID("password").value = $password
$ie.Document.getElementByID("login-button").click()
while ($ie.busy -eq $true) {start-sleep -seconds 1}
if ($ie.Document.url -eq $landingPage) {
#success
} else {
#failure
}
$ie.quit()
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($ie) | out-null
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
$process = get-process -name "iexplore"
while ($process) {
try {
stop-process -name "iexplore" -ea stop
} catch [Microsoft.PowerShell.Commands.ProcessCommandException] {
#do nothing
}
try {
$process = get-process -name "iexplore" -ea stop
} catch [Microsoft.PowerShell.Commands.ProcessCommandException] {
$process = $null
}
}
Until I can figure out what the problem is, I've implemented a workaround. I put the offending code in a try block. In the catch block, I restart the script. Following is not exactly how it is implemented in my script but it gives you the idea:
try {
$ie.Document.getElementByID("username").value = $username
} catch {
start powershell {$scriptPath}
exit
}
When the script restarts, the elements of the page can once again be accessed with getElementByID.
Related
I am trying to catch an error nicely, as I would do in Java. The program is similar to this:
try
{
New-Object System.DirectoryServices.DirectoryEntry($SearchString, $username, $pass)
Write-Ouput "Continue program"
}
catch
{
Write-Output "Some error"
}
The exception is never captured. In fact, the catch method executes when everything goes well.
From the different errors I can get, it doesn't look like an exception is raised:
format-default : The following exception occurred while retrieving member "distinguishedName": "The server is not operational.
"
+ CategoryInfo : NotSpecified: (:) [format-default], ExtendedTypeSystemException
+ FullyQualifiedErrorId : CatchFromBaseGetMember,Microsoft.PowerShell.Commands.FormatDefaultCommand
format-default : The following exception occurred while retrieving member "distinguishedName": "The user name or password is
incorrect.
"
+ CategoryInfo : NotSpecified: (:) [format-default], ExtendedTypeSystemException
+ FullyQualifiedErrorId : CatchFromBaseGetMember,Microsoft.PowerShell.Commands.FormatDefaultCommand
How can I capture these errors in a more user-friendly way?
Maybe in this case it is not possible.
After some testing, I think the problem is that no exception is raised for some reason, despite of what the error message says. So that is why I can't capture it. I have also tried to use getType, close and other methods but I get the same error:
The following exception occurred while retrieving member "GetType": "The user name or password is incorrect.
"
...
This solution does not seem to work either, same behaviour.
Question related.
need add 'erroraction'
try
{
New-Object System.DirectoryServices.DirectoryEntry($SearchString, $username, $pass) -ErrorAction Stop
Write-Ouput "Continue program"
}
catch
{
$Err = $error[0]
Write-Output $Err.Exception
}
You could also just default back to this...
If ($(New-Object System.DirectoryServices.DirectoryEntry($SearchString, $username, $pass)) -eq $false)
{Write-Verbose 'Continue program' -Verbose}
Else {Write-Warning -Message 'Something went wrong with your directory command'}
# Results
<#
WARNING: Something went wrong with your directory command
#>
... though like you try/catch is my preference. I am not in an ADDS environment to test the try/catch one at this time.
Know that you are not the only one stressed out by this. See:
Powershell DirectoryService object error neither caught nor trapped
Yet, after a bit of digging at my notes on ADDS (ADSI stuff from back in the day) in the past, here's the real deal on this namespace. The result is not really $true or $false, unlike System.DirectoryServices.AccountManagement; with what you are using, is provided with incorrect credentials you get the error. If the credentials are correct the returned object will contain a valid result, the result is Boolean output.
So, if you really want to stick with Try/Catch, do this instead:
try
{
$AuthResult = [bool](New-Object System.DirectoryServices.DirectoryEntry($SearchString, $username, $pass)).distinguishedName -ne 'False'
'Continue program'
}
catch {Write-Warning -Message 'Bad credentials passed'}
# Resuls
<#
WARNING: Bad credentials passed
#>
You of course, if so inclined you can trap error data and output as needed.
Yet, that is not much different than what the check provided in the If/Then. So, your choice.
I managed to do it with this solution:
$o = New-Object DirectoryServices.DirectoryEntry ($path, $user, $pass)
if ($path -eq 'LDAP://') {
'Computer is not member of a domain.' } elseif ($o.DistinguishedName) {
'Invalid user credentials.' } But if for some reason you must retrieve the actual error message, you can do it like this:
$o = New-Object DirectoryServices.DirectoryEntry ($path, $user, $pass)
try {
$o | Out-Default } catch {
$_.Exception.InnerException.Message }
This worked for me. The object will instantiate even though there might be an error that won't show up until you try to use it later. Using this, you can set a boolean to whether the distinguishedName was set or not:
$Entry = New-Object System.DirectoryServices.DirectoryEntry($SearchString, $username, $pass)
$succeeded = [bool]$Entry.distinguishedName
if ($succeeded)
{
Write-Ouput "Continue program"
}
else
{
Write-Output "Some error"
}
I implemented a powershell script, which assigns Exchange settings to our user mailboxes (Exchange 2016). As we have a lot of mailboxes and assigning settings is slow, the script would run more then 15 hours. However after about 10 hours I get the following error:
Processing data for a remote command failed with the following error message: Error occurred during the Kerberos response.
[Server=XXXXX, TimeStamp = 74/2018 01:25:49]
For more information, see the about_Remote_Troubleshooting Help topic.
At C:\Users\ACCOUNT\AppData\Local\Temp\tmp_cj3akhk4.osq\tmp_cj3akhk4.osq.psm1:77943 char:9
+ $steppablePipeline.End()
+ ~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (XXXX:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : JobFailure
+ PSComputerName : XXXX
My script retires the operation and after two retries (which fail) an authentication prompt is shown. There I can enter the password of the service account and the script continues. However this dialog is only visible if I run the script in a PS command prompt. If the script is started as Windows Task, it just hangs and does not continue.
The connection to Exchange is opened and imported with the following code. The code can either connect to our on premises Exchange or Exchange online based on the passed parameter. The problem is currently only happening, when connected to our local (on premises) Exchange infrastructure.
Function Connect-Exchange{
PARAM(
[parameter(Mandatory=$false)]
[String]$TargetExchange = 'Local'
)
BEGIN{}
PROCESS{
if ($ExchangeSessionInfo.Session -and $ExchangeSessionInfo.Type -eq $TargetExchange -and $ExchangeSessionInfo.Session.State -eq 'Opened'){
# Nothing to do, we are already connected.
Write-Log "Exchange connection type $($TargetExchange) already established, nothing to do."
} else {
if ($ExchangeSessionInfo.Session -and $ExchangeSessionInfo.Type -ne $TargetExchange -and $ExchangeSessionInfo.Session.State -eq 'Opened'){
# We have a open session with the wrong type. We close it.
Remove-PSSession $ExchangeSessionInfo.Session
$ExchangeSessionInfo.Session = $null
$ExchangeSessionInfo.Status = 'undefined'
$ExchangeSessionInfo.Type = ''
}
# We close all other existing Exchange sessions we created.
get-pssession -Name "Exchange" -ErrorAction SilentlyContinue | remove-pssession
# Now connect to the requestes Exchange infrastructure and import session.
$Connected = $False
$RetryCount = 5
do{
try {
If ($TargetExchange -eq 'Local'){
$ExchangeServer = Get-Random -InputObject $LocalExchangeConfig.ExchangeServers
$ExchangeSessionInfo.Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$($ExchangeServer)/PowerShell/" -Credential $EOCredentials -Authentication Kerberos -Name "Exchange"
} else {
$ExchangeSessionInfo.Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'https://ps.protection.outlook.com/powershell-liveid/' -Credential $EOCredentials -Authentication Basic -AllowRedirection -Name "Exchange"
}
$Res = Import-PSSession $ExchangeSessionInfo.Session -WarningAction SilentlyContinue -AllowClobber
# Store Exchange status in session variable.
$Connected = $True
$ExchangeSessionInfo.Status = 'connected'
$ExchangeSessionInfo.Type = $TargetExchange
} catch {
$err = Write-Error -err $error -msg "Could not connect to Exchange server type '$($TargetExchange)' (Retries left: $($RetryCount))." -Break $false
get-pssession -Name "Exchange" -ErrorAction SilentlyContinue | remove-pssession
$RetryCount -= 1
}
} while (!$Connected -and ($RetryCount -gt 0))
# If we do not have connection here, this is an error.
if (!$Connected) {
$ExchangeSessionInfo.Session = $null
$ExchangeSessionInfo.Status = 'undefined'
$ExchangeSessionInfo.Type = ''
throw "No connection to Exchange server (type: $($TargetExchange)) could be established."
} else {
# Get list of available mailbox DBs including mailbox count and create hashtable to store statistics. We only have to get it the first time.
if (($MailboxDBList.count -eq 0) -and ($TargetExchange -eq 'Local')){
Write-Log "Getting current Exchange DB configuration and mailbox count. Takes a moment."
$MailboxDBList = Get-MailboxDBCount -Type $LocalExchangeConfig.DistributeMailboxes
}
}
}
}
END{
return $ExchangeSessionInfo
}
}
The following code is applying a predefined set of Exchange settings:
...
$TryCount = 0
$Done = $false
do{
# It takes a while after enabling mailbox until settings can be applied. So we need to retry.
try{
# If we need to execute a setting several times.
if ($MailboxSetting.LoopOver){
# We have a loop value (array).
foreach ($LoopValue in $MailboxSetting.LoopOver){
# Copy parameter as we have to change a value (loop value).
$TempParams = $Params.PsObject.Copy()
#($Params.getenumerator()) |? {$_.Value -match '#LOOPVALUE#'} |% {$TempParams[$_.Key]=$LoopValue}
$res = & $MailboxSetting.Command -ErrorAction Stop #TempParams -WhatIf:$RunConfig.TestMode
}
} else {
# THE PROBLEM HAPPENS HERE
$res = & $MailboxSetting.Command -ErrorAction Stop #Params -WhatIf:$RunConfig.TestMode
}
# Write-Log "Setting command $($MailboxSetting.Command) executed successfully"
$Done = $true
} catch{
$tryCount++
$res = Write-Error -err $error -msg "Error applying mailbox settings, account: $($AccountDetails.sAMAccountName), retry count: $($TryCount)" -Break $false
Start-Sleep -s $(($Retires-$TryCount) * 5)
}
} while ((!$done) -and ($tryCount -lt $Retires))
...
I am sure the error is not related to the code, because the script runs for hours without a problem and applies all settings. However after a around 10 hours it seems the Kerberos ticket expires and then the script cannot longer access Exchange without a re-login.
Is there a way to keep the Kerberos ticket from expiring or renew it?
Any help would be appreciated.
I think you are hitting the domain security policy (group policy object - GPO) => security settings/account policy/Kerberos policy restriction.
The two valid options for you are:
Maximum lifetime for user ticket => the default value is 10 hours
Maximum lifetime for user ticket renewal => the default value is 7 days (this is the period within which the ticket can be renewed).
Is there a way to keep the Kerberos ticket from expiring or renew it?
For the first questions you "just" need to adjust the maximum lifetime for user ticket setting to value as you deem appropriate.
The second one is more tricky. I would just purge all kerberos tickets via the powershell. For more - viewing and purging cached kerberos tickets which would get you a new one.
If the ticket can be renewed you have to check the RENEABLE flag - you wan view it via kinit. Perhaps kinit -R could be enough for ticket renewal. (I did not do this my self) You could also renew it via kerberos for windows
Edit -- adding klist purge to purge all Kerberos tickets so it can be renewed.
As you have klist then you can purge all tickets via must be run in elevated powershell prompt
(all credits to JaredPoeppelman):
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Then check if your TGT was updated via:
klist tgt
Note: you must use FQDN name everywhere!
Thanks for your suggestion. In a first try I will extend my code as follows and try to reestblisch a new Exchange connection. Needs 10 h runnig the script in order to see if this works.
I am not able to influence the domain security Policy, additionally as I do not know how long the script runs, it will be difficult to set a value.
On my Windows 2016 the command "kinit" ist not recognized. Possibly I need to install additional modules/roles.
...
$TryCount = 0
$Done = $false
do{
# It takes a while after enabling mailbox until settings can be applied. So we need to retry.
try{
# If we need to execute a setting several times.
if ($MailboxSetting.LoopOver){
# We have a loop value (array).
foreach ($LoopValue in $MailboxSetting.LoopOver){
# Copy parameter as we have to change a value (loop value).
$TempParams = $Params.PsObject.Copy()
#($Params.getenumerator()) |? {$_.Value -match '#LOOPVALUE#'} |% {$TempParams[$_.Key]=$LoopValue}
$res = & $MailboxSetting.Command -ErrorAction Stop #TempParams -WhatIf:$RunConfig.TestMode
}
} else {
$res = & $MailboxSetting.Command -ErrorAction Stop #Params -WhatIf:$RunConfig.TestMode
}
# Write-Log "Setting command $($MailboxSetting.Command) executed successfully"
$Done = $true
} catch{
$tryCount++
$res = Write-Error -err $error -msg "Error applying mailbox settings, account: $($AccountDetails.sAMAccountName), retry count: $($TryCount)" -Break $false
Start-Sleep -s $(($Retires-$TryCount) * 5)
try{
# We may have lost the Kerberos ticket, reconnect to Exchange.
$ConnectionType = $ExchangeSessionInfo.Type
Disconnect-Exchange
Connect-Exchange -TargetExchange $ConnectionType
} catch {}
}
} while ((!$done) -and ($tryCount -lt $Retires))
...
I have weird problem, when im using try/catch method for some cmdlets its working for some not.
Can you advice on that?
This one is working fine:
try
{
$LookingForRemoteMailboxOnPrem = Get-RemoteMailbox $info -ErrorAction Stop | select -ExpandProperty UserPrincipalName
}
catch
{
string]$t = $Error[0]
}
But this one is not:
try
{
$EnableRemoteMailbox = Enable-RemoteMailbox $info -RemoteRoutingAddress $remote -PrimarySmtpAddress $info2 -ErrorAction Stop
}
catch
{
[string]$t = $Error[0]
}
Not saving error to $t variable
The $ErrorActionPreference is set to Continue by default. This means if PowerShell can "recover" from an error it won't throw an exception. You can use the -ErrorAction parameter to change the behaviour at every cmdlet.
This link gives a good example:
Try {dir c:\missingFolder}
Catch [System.Exception] {"Caught the exception"}
Finally {$error.Clear() ; "errors cleared"}
The string "Caught the exception does not occur in PowerShell windows. If you set the -ErrorAction to Stop an exception is raised.
Details are described here.
i try to do error handling within my powershell script. but i always get an fatal. i tried a few things, e. g. try{ } catch{ } - but i did it not get to work.
any ideas or Solutions?
Function Check-Path($Db)
{
If ((Test-Path $Db) –eq $false) {
Write-Output "The file $Db does not exist"
break
}
}
It Returns:
Test-Path : Zugriff verweigert
In K:\access\access.ps1:15 Zeichen:6
+ If ((Test-Path $Db) -eq $false) {
+ ~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (K:\ss.mdb:String) [Test-Path], UnauthorizedAccessException
+ FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.TestPathCommand
Somewhat confusingly Test-Path actually generates an error in a number of cases. Set the standard ErrorAction parameter to SilentlyContinue to ignore it.
if ((Test-Path $Db -ErrorAction SilentlyContinue) -eq $false) {
I cannot answer directly. So this has to do:
I strongly disagree with your answer. Test-Path does show $false when you run it against a network share that is not accessible, but it will be false also (without Exception) when the Server is not reachable.
So your answer simply ignores anything but a reachable share.
What is neccessary however is a try-catch-block that handles this better:
[cmdletbinding()]
param(
[boolean]$returnException = $true,
[boolean]$returnFalse = $false
)
## Try-Catch Block:
try {
if ($returnException) {
## Server Exists, but Permission is denied.
Test-Path -Path "\\Exists\Data\" -ErrorAction Stop | Out-Null
} elseif ($returnFalse) {
## Server does not exist
Test-Path -Path "\\NoExists\Data\" -ErrorAction Stop | Out-Null
}
} catch [UnauthorizedAccessException] {
## Unauthorized
write-host "No Access Exception"
} catch {
## an error has occurred
write-host "Any other Exception here"
}
The really important part however is the ErrorAction on the Test-Path command, otherwise the exception will be wrapped around a system management error and is thus not catchable. This is in detail explained here:
PowerShell catching typed exceptions
I'm using PowersHell to automate iTunes but find the error handling / waiting for com objects handling to be less than optimal.
Example code
#Cause an RPC error
$iTunes = New-Object -ComObject iTunes.Application
$LibrarySource = $iTunes.LibrarySource
# Get "playlist" objects for main sections
foreach ($PList in $LibrarySource.Playlists)
{
if($Plist.name -eq "Library") {
$Library = $Plist
}
}
do {
write-host -ForegroundColor Green "Running a loop"
foreach ($Track in $Library.Tracks)
{
foreach ($FoundTrack in $Library.search("$Track.name", 5)) {
# do nothing... we don't care...
write-host "." -nonewline
}
}
} while(1)
#END
Go into itunes and do something that makes it pop up a message - in my case I go into the Party Shuffle and I get a banner "Party shuffle automatically blah blah...." with a "Do not display" message.
At this point if running the script will do this repeatedly:
+ foreach ($FoundTrack in $Library.search( <<<< "$Track.name", 5)) {
Exception calling "Search" with "2" argument(s): "The message filter indicated
that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVER
CALL_RETRYLATER))"
At C:\Documents and Settings\Me\My Documents\example.ps1:17 char:45
+ foreach ($FoundTrack in $Library.search( <<<< "$Track.name", 5)) {
Exception calling "Search" with "2" argument(s): "The message filter indicated
that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVER
CALL_RETRYLATER))"
At C:\Documents and Settings\Me\My Documents\example.ps1:17 char:45
If you waited until you you had a dialog box before running the example then instead you'll get this repeatedly:
Running a loop
You cannot call a method on a null-valued expression.
At C:\Documents and Settings\Me\example.ps1:17 char:45
+ foreach ($FoundTrack in $Library.search( <<<< "$Track.name", 5)) {
That'll be because the $Library handle is invalid.
If my example was doing something important - like converting tracks and then deleting the old ones, not handling the error correctly could be fatal to tracks in itunes.
I want to harden up the code so that it handles iTunes being busy and will silently retry until it has success. Any suggestions?
Here's a function to retry operations, pausing in between failures:
function retry( [scriptblock]$action, [int]$wait=2, [int]$maxRetries=100 ) {
$results = $null
$currentRetry = 0
$success = $false
while( -not $success ) {
trap {
# Set status variables at function scope.
Set-Variable -scope 1 success $false
Set-Variable -scope 1 currentRetry ($currentRetry + 1)
if( $currentRetry -gt $maxRetries ) { break }
if( $wait ) { Start-Sleep $wait }
continue
}
$success = $true
$results = . $action
}
return $results
}
For the first error in your example, you could change the inner foreach loop like this:
$FoundTracks = retry { $Library.search( "$Track.name", 5 ) }
foreach ($FoundTrack in $FoundTracks) { ... }
This uses the default values for $wait and $maxRetries, so it will attempt to call $Library.search 100 times, waiting 2 seconds between each try. If all retries fail, the last error will propagate to the outer scope. You can set $ErrorActionPreference to Stop to prevent the script from executing any further statements.
COM support in PowerShell is not 100% reliable. But I think the real issue is iTunes itself. The application and COM model wasn't designed, IMO, for this type of management. That said, you could implement a Trap into your script. If an exception is raised, you could have the script sleep for a few seconds.
Part of your problem might be in how $Track.name is being evaluated. You could try forcing it to fully evaluate the name by using $($Track.name).
One other thing you might try is using the -strict parameter with your new-object command/