<Management pack name> could not be imported.
If any management packs in the Import list are dependent on this management pack, the installation of the dependent management packs will fail.
System.TimeoutException: The requested operation timed out. —> System.TimeoutException: This request operation sent to net.tcp://<hostname>:5724/DispatcherService did not receive a reply within the configured timeout (00:29:59.5368709). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
I recently encountered the above error when importing a custom (sealed) management pack, and struggled with it for quite some time. Was the cause that the management pack was simply too large? Was there a SQL Server performance problem? Perhaps there was a timeout config error on the management server?
Eventually I traced the problem to an error in the
<Resources> section of the management pack: there were references to files that didn’t exist.
<Image ID=”DistributedApplications.Image.Crepe16″ Accessibility=”Public” FileName=”Cr├¬pe1680.png” />
<Image ID=”DistributedApplications.Image.Crepe80″ Accessibility=”Public” FileName=”Cr├¬pe8080.png” />
The mistake was that files by the names specified weren’t present in the management pack; this was simply a typo. I would have thought this would cause an error to be thrown in the console, but instead SCOM attempts to import the management pack, appears to silently fail part-way through the process, then the SDK service waits for the above timeout. The solution was to simply provide the correct file names.