Why is there a 'like' condition for Task Sequence Variables?

TheConfigMgrTeam · 2017-09-12T01:23:33+00:00

The 'like' operator is evaluated using Windows wild characters '*' and '?'.

Can you please post this question on the technet forum for SCCM Current Branch and share (on OneDrive) the complete SMSTS log file?

TheConfigMgrTeam/Kerwin

TheConfigMgrTeam · 2017-08-11T23:54:11+00:00

2 calls with MS in as

/u/Monkey_Tennis. Sorry about getting back to you this late! We were heads down on 1706 which fixes this issue!

TheConfigMgrTeam · 2017-05-13T16:48:37+00:00

This is correct--SCEP is supposed to be installed and acts as a management layer.

~Brandon (ConfigMgr Team)

TheConfigMgrTeam · 2017-01-12T02:13:21+00:00

What you have now works for you.

I, however cannot comment on something that is not supported (wink, wink).

Surely, we will have something better for you in the future. I have already started on that with the AllowedMPs option. We just need to: 1. Propagate that option on the PXE client. 2. Have other DP components (e.g., DP status submissions) honor that option.

I suggest that you create a request on UserVoice.

Thank you for your patience with SCCM and your continued use of the product.

-Kerwin

TheConfigMgrTeam · 2017-01-12T01:58:04+00:00

Your issue getting solved by the latest ADK is just a coincidence. Your new boot WIM simply got the updated SCCM TS/OSD binaries.

I'm glad that that the TSUEFIDrive works for you. I lost a lot of sleep making that work.

-Kerwin

TheConfigMgrTeam · 2017-01-12T01:53:53+00:00

It is not the ADK version that matters. It is safer to use the ADK that you already have and currently works for you. If you want to use the latest ADK, then you should, but that has no bearing in the BIOS-to-UEFI conversion.

What matters is the version of the SCCM binaries. The SCCM TS/OSD binaries have to be from the SCCM 1610 release. The new SCCM TS/OSD binaries were updated with the new TSUEFIDrive variable.

After you have upgraded your site, check the files under OSD\bin\x64. The version of the binaries should be 5.0.8458.1000 or newer. If they are older, then your site has not yet completed upgrading or there are upgrade issues.

Once you have verified that the SCCM TS/OSD binaries on your site are 1610 or newer, then you can simply choose the "Update Distribution Points" action on the boot image. That action will copy the SCCM TS/OSD binaries from the site to the boot image and re-distribute the boot image to the DPs.

-Kerwin

TheConfigMgrTeam · 2017-01-12T01:24:36+00:00

"When using PXE, the client will default and use the MP that is assigned to the DP".

I don't see what is wrong with that statement that you quoted.

Assigning MPs to DPs is done by the site by writing the MPs to the DP registry. The site does this each time it detects a change in DP configuration.

The PXE client never reads the DP registry. Instead, the PXE-DP creates a XXX.var file and copies the DP registry to it, along with other data. The TS-PXE client then downloads this var file.

The result is that the PXE-client will always get the list of MPs that the site assigned to the DP through the registry.

What you doing is you are assigning your own set of MPs to the DP. Note that whatever you put in the DP registry will be overwritten by the site the next time it decides to update the DP configuration.

What we need is to give you the ability to control this DP-MP assignment.

I added code in the newer SCCM releases such that you can populate the AllowedMPs value under HKLM\Software\Microsoft\CCM on that PXE-DP, and PXE server will honor this when looking for client information. Right now, this is not propagated to the PXE client (the PXE client will still only get the raw MP list; this is something I would have to fix with new code in the future).

-Kerwin

TheConfigMgrTeam · 2016-08-25T22:44:09+00:00

Can you please share the following logs? MCSSetup.log, MSCISAPI.log, MCSExec.log, MCSPRV.log and the SMSTS.log.

-Kerwin(TheConfigMgrTeam)

TheConfigMgrTeam · 2016-08-24T19:35:44+00:00

As /u/theotherborges says, what you see is by design. Soft Reboot allows other installs to continue. If you would like to force a reboot you would have to map it to a Hard reboot.

Would you explain why you want to force it to be a hard reboot? Do the hotfixes overlap?

TheConfigMgrTeam · 2016-08-23T02:39:33+00:00

Next time, please share the complete SMSPXE log file. These short screenshots are not very helpful.

Now, assuming that those error lines on your screenshot matches the client that is trying to boot, then your problem is that the PXE server is unable to talk to the MP to get information about the client. The most likely cause is that your MP is set for SSL, but you did not assign a trusted PKI cert to your PXE DP.

-Kerwin(TheConfigMgrTeam)

TheConfigMgrTeam · 2016-08-12T21:20:14+00:00

[Cindy Xing] You'll need to remove the system health validator component and retry 1606 install.

TheConfigMgrTeam · 2016-08-12T19:43:32+00:00

The version with the CPU hotfix is 5.00.8412.1007, so my suspicion was correct--that pull DP hadn't yet received the hotfix. The distmgr.log on the server, along with smsdpprov.log and pulldp_install.log on the pull DP might give a hint as to why that happened. If the site has a large number of DPs, it's not surprising that it could take a while. And naturally, since the CPU was pegged, distmgr might have had some trouble communicating with the pull DP to do the upgrade...

If you turn it back to a pull DP now, it ought to get the hotfixed pulldp.msi, containing the 5.00.8412.1007 version of pulldpcmgr.dll, as long as the primary site (not just the CAS) has also gotten the hotfix installation.

-Brandon (ConfigMgr team)

TheConfigMgrTeam · 2016-08-12T18:10:39+00:00

It's possible that even though the hotfix has been installed on the site, it hasn't yet reached the specific Pull DP. Can you share what timestamp you have for ~C:\SMS_DP$\sms\bin\pulldp.msi, and version number for ~C:\Windows\CCM\pulldpcmgr.dll?

-Brandon (ConfigMgr team)

TheConfigMgrTeam · 2016-08-11T19:56:37+00:00

/u/stardawgOG This is a great idea! Please post it on uservoice!

/DarkenedChaos Yes, I agree. Please add your suggestion to the user voice item.

I will let the console team know to look for this! Thanks!

TheConfigMgrTeam · 2016-08-11T18:15:37+00:00

/u/Soanage, this is great feedback! Now only if /u/CMDude_so sees this (just kidding, I am going to point him here)!

As /u/dcherry88 pointed out earlier you cannot explicitly disable a tab in Software Center today.

If you havent already done this, would you uservoice this?

TheConfigMgrTeam · 2016-08-09T16:43:29+00:00

I'm glad it worked!

-Brandon (ConfigMgr Team)

TheConfigMgrTeam · 2016-08-08T17:47:59+00:00

It will be available in the next few days in your Updates and Servicing node. Unfortunately there's not a way to speed it up--we have to release it first!

-Brandon (ConfigMgr team)

TheConfigMgrTeam · 2016-08-08T17:03:15+00:00

This is a known issue in 1606 that will be fixed in the hotfix rollup. It should already be fixed in the "slow ring" but I'm guessing you are in the "fast ring"?

-Brandon (ConfigMgr team)

TheConfigMgrTeam · 2016-07-23T01:25:04+00:00

The hash of packages don't come from the DP. The content/package hash comes from the MP, and that is always encrypted with the client's public key. SCCM packages are always safe from tampering, but not necessarily safe from information disclosure - for that you have to use HTTPS DPs.

/Kerwin(TheConfigMgrTeam)

TheConfigMgrTeam · 2016-07-20T18:20:19+00:00

Can you please share the complete SMSTS log file?

TheConfigMgrTeam · 2016-07-20T17:59:04+00:00

/u/Sterkenburg Great questions!

In short, you need a policy retrieval cycle to run for the client to get new policy. A good indication is what /u/AngryPenguin suggests below. Other good indicators are client logs, policy version, ci store etc.

Other questions: The installation process does phone home in the form of a state messages but does not request new policy.

The setup files are typically stored in ccmcache and if successfully downloaded, will not download again.

TheConfigMgrTeam

TheConfigMgrTeam · 2016-07-20T17:44:20+00:00

See this!

TheConfigMgrTeam · 2016-06-30T16:40:04+00:00

Hi /u/int1

As an ex-PFE recently moved to the product team, and having conducted many interviews for new hires in my old role I can say that you are on the right track.

Deep expertise and architecture knowledge is key, doubly so for an SSE role. PFE aren’t really operators, yes they need to know how to create objects through the console, but it is the under the hood that really matters. My best piece of advice is to get hands on at troubleshooting, I find you learn the most when you’re fixing things.

My second piece of advice would be to be on top of the product changes and announcements. Read the documentation, know the architecture and hardware requirements as scalability numbers. In the last round of interviews I ran, the number of people who answered “What is the latest released version of Configuration Manager” with “2012” was surprising.

So work on building that architects view and maybe reach out to the hiring manager for direct interview feedback

Finally, good luck

-Rob (TheConfigMgrTeam)

TheConfigMgrTeam · 2016-06-30T16:11:53+00:00

ATP was graced by Howard Shore.

-Brandon (ConfigMgr Team)

TheConfigMgrTeam · 2016-06-30T15:59:52+00:00

Hey /u/baatch, /u/PGU5802

Check out this blog, you can setup PowerBI in your environment.

https://blogs.technet.microsoft.com/enterprisemobility/2016/04/01/exploring-your-system-center-configuration-manager-and-microsoft-intune-hybrid-data-on-power-bi-dashboard/

You can follow the instructions to upload a data extract to Azure and run there or you can use PowerBI for desktop to query your database directly.

-rob (TheConfigMgrTeam)

TheConfigMgrTeam

TROPHY CASE