# NOTE: I moved to http://www.thesccm.com

How is this related with SCCM? No, it doesn’t 🙂

But because of Adobe Reader was deployed by SCCM, and there is print problem, so it became “SCCM package” problem, and it became my problem. 🙂

So the problem is when open a pdf file in IE, when you click this little “print” icon in IE, we got an error from Adobe Reader “Bad parameter.”

Although I am 100% sure nothing wrong with our Adobe Reader SCCM package, but I intend to find out what is the reason.

This is the setting what cause this “print issue” in my case.

Computer Configuration\Policies\Windows Components\Internet Explorer\Internet Control Panel\Advanced Page
Turn on 64-bit tab processes when running in Enhanced Protected Mode on 64-bit versions of Windows

It was set “Enabled”. As “Help” mentioned, Some ActiveX controls and toolbars maybe not be available when 64-bit processes are used.

As you see, Adobe Reader XI is using 32-bit processes, so in this case, it stop working. (I am using 64-bit Windows 10)

I would suggest set it “Disable” or “Not Configured” if you wants to use Enhanced Protected Mode, and if you are not sure if all your ActiveX components work on 64-bit processe.

This setting you will find in your IE:

Internet Options->Advanced->Settings->Security->Enable 64-bit processes for Enhanced Protcted Mode

By change this setting in GPO “Disable” or “Not Configured”, or uncheck that in IE Advanced Setting, it fixed “bad parameter” problem.

# NOTE: I moved to http://www.thesccm.com

Setup my test lab in this weekend to test SCCM TP 1609, and my PXE boot failed. SMSPXE.log shows:

RequestMPKeyInformation: Send() failed.
Unsuccessful in getting MP key information. 80004005.
PXE::MP_InitializeTransport failed; 0x80004005
PXE::MP_ReportStatus failed; 0x80070490,
PXE::CPolicyProvider::InitializeMPConnection failed; 0x80070490

When tried to open MP list, http://my_sccm_server/sms_mp/.sms_aut?mplist, it gave me HTTP Error 500.19

Error Code 0x800700e, unable to load DLL.

So what happend? Well, because I uninstalled WSUS (not ask my way, I had my reason. 😀 ), applicationHost.config files didn’t updated itself.

How to fix it:

Open “C:\Windows\System32\inetsrv\config\applicationHost.config”, search “suscomp.dll”, and remove the whole line.
Problem soveled.

<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Program Files\Update Services\WebServices\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />

Well, you can also install WSUS back, it will fix the problem for you. 🙂

# All components Type and Availability shows “Unknown”. Failed to read the required Operations Management component registry key values on local computer; error = 6 (0x6).

This morning, I noticed in our SCCM Primary server, all components Type and Availability shows “Unknown”

After awhile, “Type” and “Availability” shows correctly, about 60 minutes later, it shows “Unknown” again, and it just repeatedly changes itself. We rebooted the server, but it didn’t help.

Investigating further, I saw that the compmon.log on the site server displayed the following errors:

"Failed to read the required Operations Management component registry key values on local computer; error 6 (0x6)"

And it repeatedly try to  add all the components to monitored component list again and again about each hour.

I found this post has same kind issues http://sccmstuff.com/troubleshooting/compmon-log-errors-6-0x6/ ,  so I start check our registry, found out what is our problem key:

HKLM\Software\Microsoft\SMS\Operations Manager\Components\SMS_NETWORK_DISCOVERY

This registry key was empty, unlike other components registry keys. I remember we tested use Network Discovery to create boundaries automatically, but later we decided not to use Network Discovery and we deselected it. It seems the component’s registry has left behind.

I made a backup of the Components registry, deleted SMS_NETWORK_DISCOVERY registry key, restarted SMS_EXECUTIVE service. The log is clear without errors. It didn’t try to add those components to monitored list again. All components shows status correctly.

# SCCM 1606 BUG? 32-bit process Powershell detection method doesn’t work

As you know, you can use powershell detection method when you create Application in SCCM.

Usually, I use this script, and it has been working for many years:

$app = Get-WmiObject Win32Reg_AddRemovePrograms | where-object {$_.DisplayName -like “Your Application name”}
if ($app -ne$null) {
write-host Installed
}

I choosed “Run script as 32-bit process on 64-bit clients”. Because clients are 64bits Windows 10 machines, and my application is 32-bits.

As usual, I tested the detection script in my machine that has the application already installed. Run the script in ISE (x86), it will get you “Installed”. If run it in ISE (x64), it gives you nothing.

Yesterday, users complains softwares are trying to install again and again, and I started to check out what is going on.

I checked “C:\Windows\CCM\Logs\AppDiscovery.log” in few machines, applications that are using this 32-bit powershell detection method gave result “not detected”, although applications are installed.

No one has changed those Applications detection method, I wonder what went wrong.

At the end, I found the “Run script as 32-bit process on 64-bit clients” powershell dection method didn’t work right after machines have updated SCCM Client 1606. 5.00.8412.1007, based on time stamp of ccmsetup.log and AppDiscovery.log.

I have tested few more Applications, results are same.

# A computer that is running Windows 10 Version 1511 reverts to a previous date and time

Perhaps not many people have this issue, but I would like to mention it here.

The system date and time setting on a computer that is running Windows 10 Version 1511 (build 10586.xx) incorrectly reverts to a date and time that is at least one day in the past.

https://support.microsoft.com/en-us/kb/3160312

If your envirment is in a private network or proxy, I suggest you run this step in your win 10 image capture process:

Net stop w32time

W32tm.exe /unregister

W32tm.exe /register

net start w32time

W32tm.exe /resync /force

How do you know you have time sync problem?

1. After machine is installed, time in the log on screen is wrong.
2. installation log file smsts.log, you will see the time is jumping in Data/Time column. (use cmtrace to read log files, not notepad)
3. machine BIOS clock might changed itself.
4. SMSTSUDAUSERS is not set

# SCCM 1602 roll up hotfix KB3155482 bug?

NOTE: the KB has been updated with a workaround for this issue
https://support.microsoft.com/en-us/kb/3155482

Lovely weekend, upgraded from SCCM 2012 R2 SP1 CU2 to 1511, then 1602, then hotfix KB3155482. At the end, we end up exectly like this, Client Upgrade shows old client version numbers, and SCCM Client package is not updated.

Big thanks for Niall Brady ‘s windows-noob Facebook group, Anderz Wedefelt point me out technet forum has same discussion of this matter, –Marc–  has reported as bug to MS. https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/2803952

So if you don’t wanna end up like me, please remember promote automatic client upgrade to production before you install this hotfix to your site system.

Here is the fix, Wrex mentioned it in technet forums:

1. If you have another test envirment what is upgraded sucessfully, copy all the files from CMUClient from that server to your CMUClient folder, go to step 3.
2. If you don’t have another test envirment you can copy those files from, do this:
Go to EasySetupPayload folder, you will find two folders inside it. Sort them with time stamp, the older one is 1602 installation media, new one is hotfix KB31554821) Open the 1602 folder:
1.1) copy all files from “SMSSETUPCLIENT” to “your SCCM installation pathCMUClient”
1.2) copy msrdcoob_amd64.exe, wic_x64_enu.exe and WindowsUpdateAgent30-x64.exe from “redist” to “your SCCM installation pathCMUClientx64”
3)copy ndp452-kb2901907-x86-x64-allos-enu.exemsrdcoob_x86.exe, silverlight.exe, wic_x86_enu.exe, windowsupdateagent30-x86.exe from “redist” to “”your SCCM installation pathCMUClienti386”

(Optional)
If you have choose multiple language in your site, copy also language pack from “redistLanguagePackClient”
Example. Finnish launguage, choose FIN folder, copy “redistLanguagePackClientFINsmssetupClient” to “your SCCM installation pathCMUClient”
2) Open the hotfix folder:

copy all files from “SMSSETUPCLIENT” to “your SCCM installation pathCMUClient”, overwrite older files.

3. Open “SQL Manangement Studio”, choose your CM site database, right click, create “new query”, excute this:
select * from ClientBaseline
select * from ClientDeploymentSettingsYou will see version are “5.00.8325.1000”
UPDATE ClientBaseline SET Version = ‘5.00.8355.1306’ WHERE Name = ‘Staging Baseline’
select * from ClientBaseline
select * from ClientDeploymentSettings

You will now see Staging Baseline version is “5.00.8355.1306”

4. Update “Configuration Manager Client Piloting Package” package. Open Admin console, go to Applications-Packages, Choose “Configuration Manager Client Piloting Package”, Click update distribution points.Wait until if finished. If you don’t see “Configuration Manager Client Piloting Package”, close Admin console and reopen Admin console as Administrator.
5. Check your site hierarchy settings, Client upgrade tab. Pre-production client version should be “5.00.8355.1306”. Uncheck “Upgrade all clients in the hierachy using production client”, if it was checked..
6. Now you should able to choose Client Update Options again.
7. Choose “I am ready to make pre-production client version available to production”, then OK.
8. Check your site hierarchy settings, Client upgrade tab. Production client version should be updated as “5.00.8355.1306”. Check the “Upgrade all clients in the hierachy using production client” check box. then click OK.
9. Check you SMSClient folder, those files should be updated themself now, and the “Configuration Manager Client Package” should be automatic updated to distribution points.

Hope this helped you!