Skip to main content
Start a Conversation

Unsolved

This post is more than 5 years old

motert

7 Posts

29080

September 9th, 2011 10:00

DTK package creation failing during install for DDP

I'm trying to install DDP on a new site server, most recent everything, 2008 R2 SP1, SCCM 2007 SP2 R3, SQL 2008 R2 SP1 and have run in to the "Cannot write to a closed TextWriter." error. Following is the exception excerpt from _Installer.log. It is able to create the folder for the package, it shows up in the console, it just doesn't seem to be able to create the package.

9/9/2011 11:06:00 AM :: Path to file is relative to: 'SiteUncShare'
9/9/2011 11:06:00 AM :: Relative path was translated to '\\SYS-SCCM01\SMS_SYS\OSD\Lib\Packages\Deployment\Dell\PowerEdge\DTK'
9/9/2011 11:06:00 AM :: Package to update: PowerEdge Deployment Toolkit Integration
9/9/2011 11:06:00 AM :: ProcessSWDPackage returned an error Cannot continue
9/9/2011 11:06:00 AM :: Processing the XML file exited with an error (1)

...

Exception encountered:
Type:WqlQueryException
Message:The ConfigMgr Provider reported an error.
Source:AdminUI.WqlQueryEngine
Data:System.Collections.ListDictionaryInternal
TargetSite:Void Put(Microsoft.ConfigurationManagement.ManagementProvider.ReportProgress)
InnerException:
System.Management.ManagementException: Generic failure
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObject.Put(PutOptions options)
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Put(ReportProgress progressReport)
StackTrace:
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Put(ReportProgress progressReport)
at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Put()
at Microsoft.ConfigurationManagement.IntegrationDevelopmentKit.SccmObjectInstaller.ProcessSWDPackage(XmlNode packageNode, String action)

Any ideas?

Todd

DELL-Warren B

1.1K Posts

September 9th, 2011 14:00

I've heard of an issue with package paths causing an failure if they were too long. Since the most recent entry in the logs before the failure was enumerating the path, it makes me suspect it.

motert

7 Posts

September 9th, 2011 21:00

hmm, this is exactly as long a path as on another server where the install works ok, so, i think that rules that out. any other ideas? it looks like it's having issues "putting" something in the swdpackage, which is the name of the node in the xml where all of the package properties are like manufacturer, version, name, description, source path, etc. it seems like there's something about the fields or the data that it's trying to put into the package that it can't or it won't fit, or something. consequently it parses the first part of the file fine, because it makes the folder where the package ends up, it just can't create the package for some reason.

Sumanth BR

29 Posts

September 28th, 2011 22:00

As you have mentioned that OS is R2 while installing are you using an Admin account?.
Have you tried installing by using Launch a Command Prompt as administrator (R-click, 'Run as Administrator'), and execute the installation from the command prompt.

motert

7 Posts

September 29th, 2011 05:00

Yes. We finally rebuilt the site server and used CU4 with SQL 2008 R2 and the install completed. Between our central site, where the install worked correctly, and this new primary child, the patch level of SQL was the only difference, and taking SQL back down to CU4 from SP1 proved to solve the issue. There were also some other issues with naming packages as the new primary child was joined to the heirarcy before the install, so to the installer there were packages and folders with the names it was trying to create there already, because they'd been synced from the central site. We're moving the OSD function from the central site to this new site, so for this transition period we have some extra challenges, as the driver inport from the DVD also fails due to package and folder name issues. So for now, until we get everything moved around our task sequences use a mish-mash of packages from multiple sites. We're trying to vacate our central site to follow best practice, so we'll remove all of the OSD stuff eventually, we just have extra work to do until we do.

Sumanth BR

29 Posts

September 29th, 2011 06:00

Good to know that issue is resolved!

View More

View All

No Events found!

Top