- UNIFYBroker Forum
- PowerShell connector
-
Questions
The network path was not found
I suddenly have an error with a connector that is one of three identical Powershell connectors (same underlying scripts, just different parameters specifying target domain). The data gathering part of the script is working fine. The script is also getting through the entire entity creation loop (I have dropped detailed logs), but is then failing after that (ie at the end of the script) with 0 entities created.
This is the error reported in the IdB log:
Change detection engine import all items failed. Change detection engine import all items for connector PowerShell HomeFolder Protected failed with reason One or more errors occurred.. Duration: 00:08:50.4965198 Error details: System.AggregateException: One or more errors occurred. ---> System.ComponentModel.Win32Exception: The network path was not found --- End of inner exception stack trace --- at Unify.Product.IdentityBroker.PowerShellConnector.d__30.MoveNext() at System.Linq.Buffer`1..ctor(IEnumerable`1 source) at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source) at Unify.Product.IdentityBroker.AuditReadingConnectorDecorator.GetAllEntities(IStoredValueCollection storedValues, CancellationToken cancellationToken) at Unify.Product.IdentityBroker.EventNotifierReadingConnectorDecoratorBase`1.GetAllEntities(IStoredValueCollection storedValues, CancellationToken cancellationToken) at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.ImportAllChangeProcess() at Unify.Product.IdentityBroker.ChangeDetectionImportAllJob.RunBase() at Unify.Framework.DefinedScopeJobAuditTrailJobDecorator.Run() at Unify.Product.IdentityBroker.ConnectorJobExecutor.<>c__DisplayClass30_0.b__0() at Unify.Framework.AsynchronousJobExecutor.PerformJobCallback(Object state) ---> (Inner Exception #0) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #1) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #2) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #3) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #4) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #5) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #6) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #7) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #8) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<--- ---> (Inner Exception #9) System.ComponentModel.Win32Exception (0x80004005): The network path was not found<---
Answer
It looks like Matt's theory that it was to do with the script (which is enumerating home folders) was correct - there must be some invalid home folder paths on user accounts but for some reason the errors are getting saved up until the import script finishes running, and then the whole import is getting killed. I've had plenty of other types of errors while developing these scripts but it's the first time I've seen it behave in this way. Anyway adding a "Test-Path" in the script has helped, so this can be closed.
Thanks for the update Carol. It is strange that it's saving the error until the end of the script - we'll do some investigation to see if we can work out why that's happening.
Forgive my understanding of PowerShell... Could it be a different setting for $PSDefaultParameterValues for each environment? I.e. different $ErrorAction / $ErrorActionPreference.
This was my first thought too. I expect this ticket is related to Access denied importing Boolean value, in which we also discussed changes to $ErrorActionPreference.
I think I actually removed the Test-Path after that! I am now setting $ErrorActionPreference="Stop" at the top of all my IdB scripts - however handling error reporting is very fiddly with errors reported in a variety of ways back to IdB, or MIM, or not at all, depending on which powershell command you're using. I'll try and contribute some extra detail to the KB page about it once I get this lot into Prod.
This happened again during the Prod deployment on the weekend. There are some issues with the source data, and I did manage to work around them, though this is often not possible during a weekend deployment.
This behaviour is particularly bad because the script runs through the entire data collection process and then fails just at the point where it should start creating the entities - which may be the way I've written my script but I do prefer to keep the two processes separate. This meant the import running for up to an hour before failing to create any entities - this is a bad thing during a deployment window.
I would prefer that IdB creates the entities even if there have been errors in the import script before that. If that isn't possible then second option is that it fail straight away on the first error, so I don't have to wait so long to find out there's a problem.
It wouldn't be a full import if it let it succeed with a subset of the entities. You can always update your script to be resilient (or retry) based on whatever condition you like - if you determine that a subset could be considered a full import (and be okay with entities disappearing).
What version of Identity Broker are you running? I could give you a patch that checks the error collection more frequently?
Customer support service by UserEcho
Thanks for the update Carol. It is strange that it's saving the error until the end of the script - we'll do some investigation to see if we can work out why that's happening.