How to apply this DLL in Powershell 2.0 code

Apr 29, 2013 at 8:32 AM
I tried importing this dll in Powershell but I got the following error:
Import-Module : Could not load file or assembly 'file:///D:\sccmclictr.automation.dll' or one of its dependencies. This
 assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
After some searching, it appears that Poweshell 2.0 does not support .NET 4.0 assemblies. I found some workarounds here but I do not want to touch registry settings in our production environment as much as possible.

What might be the best way to integrate this great dll in Powershell? Or is it possible to safely do it?

Actually, my end goal is to try this "solution" on the last post.
Apr 29, 2013 at 11:12 AM
What exactly are you planning to do... The "solution" is accessing the "old" Package/Advertisement Model which is currently not implemented in the sccmclictr.automation.dll. If you want to access Packages/Advertisements then you may have to use the older smsclictr.automation.dll which is based on .NET 3.5.

The sccmclictr.automation.dll provides for most activities a powershell command (like in ClientCenter for CM12). For simple activities, it may not be necessary to load the dll, you can directly call the related powershell commands by using powershell remoting.... but it depends what you exactly want to do...
May 4, 2013 at 5:13 AM
Thanks for the tip on the older dll. Now I have this code:
Import-Module -Name "D:\smsclictr.automation.dll"
$smsCli = New-Object -TypeName smsclictr.automation.SMSClient($computer)
Problem is, the TS failed to execute because of the ServiceWindow. On the SCCM Client GUI, you can right-click the advert and hit "Override ServiceWindow" to fix this. How can I integrate this in Powershell?
May 6, 2013 at 7:34 AM
That's a tricky one... I can't provide you powershell code, but the C# code from Client Center is Open-Source (
        private void overrideServiceWindowToolStripMenuItem_Click(object sender, EventArgs e)
            Trace.Write(sTrace + "Override ServiceWindow for selected Advertisemnet..:");
            ManagementObject MO = lv_Advertisements.SelectedItems[0].Tag as ManagementObject;
            XmlDocument xDoc = new XmlDocument();
            XmlNode xNode = xDoc.SelectSingleNode(@"SWDReserved/OverrideServiceWindows");
            xNode.InnerText = "TRUE";
            MO.SetPropertyValue("PRG_Requirements", xDoc.InnerXml);

            toolStripStatusLabel1.Text = "Override ServiceWindow activated...";
            Trace.WriteLine(sTrace + toolStripStatusLabel1.Text);
It does modify the local advertisement policy... You can get that with SoftwareDistribution.GetAdvertisements("Machine") to get all policies, or SoftwareDistribution.lGetAdverts("[PkgID]", "[ProgramID]") to get these for a specific PackageID and ProgramName.
Otherwise it's all in WMI: Namespace= "root\ccm\Policy\Machine\ActualConfig" , class "CCM_SoftwareDistribution " ... The Attribute PRG_Requirements is an embedded XML Body, where you have to set SWDReserved/OverrideServiceWindows to TRUE.

Let me know if you can convert that to powershell, otherwise I can offer you to integrate a such a function in the smsclictr.automation library...


May 6, 2013 at 9:02 AM
Thanks, here's what I did:
$advert = $smscli.softwareDistribution.lgetAdverts($tsPackageID,$tsProgramID)
$xDoc= [xml]$advert[0].PRG_Requirements
$xNode = $xDoc.SelectSingleNode("SWDReserved/OverrideServiceWindows")
$xNode.InnerText = "TRUE";
$advert[0].SetPropertyValue("PRG_Requirements", $xDoc.InnerXml)
And it finally executed the Task Sequence. Sadly, there's no time to rejoice since it failed almost immediately after kick-off.

On smsts.log
Failed to reboot the machine because the service window is not available
Failed to initialize a system reboot. 
Unspecified error (Error: 80004005; Source: Windows)
BTW, the TS starts with a System Reboot. So now the service window is not available huh....

I went back to the XMLDocument object to see if I can tweak other nodes and found this: SWDReserved/RebootOutsideOfServiceWindows. I tried setting it to TRUE but unfortunately I had the same result.

I tried manually running the same TS from RAP and it worked as expected.
May 8, 2013 at 7:33 AM
Edited May 8, 2013 at 7:34 AM
I found a workaround and that is to set a mandatory time that is far in the future (I think I haven't mentioned it before that my TS is non-mandatory. Anyway....). With this, the script finally worked (no need to worry about Service Windows).

Although I still wonder how can the script work without the mandatory time. Any idea if there's something else that needs to be set?