I have not, the only thing I’ve done is to run the maintenance task manually after deployment, rather than waiting for it to be run automatically in the middle of the night.
We haven’t had too many requests for WS2012 yet, and R2 is coming soon. I haven’t had much time to spend on it lately, but I will look at the registry entries mentioned later in this thread to see if my clients are in provisioning mode. I do recall seeing some entries in logs about provisioning, but as I recall it was that the client wasn’t in provisioning mode. The registry will tell me for sure though. I’ll let everyone know what I find when I can get back to it. Todd From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, September 15, 2013 12:34 PM To: [email protected] Subject: Re: [MDT-OSD] OSD Breaking CM12 Clients Fritz, that is exactly what our issue is no? Both win7 and win8. Todd have you been able to come up with a solution at all? Roger. Sent from Windows Mail From: Mote, Todd Sent: Sunday, September 15, 2013 12:34 AM To: [email protected] <mailto:[email protected]> I see this, but only for windows server 2012 right now. OSD completes. It even goes so far to show available software in software center, even the right name in the upper corner, the right number of actions appear in the action tab in the control panel, then couple of minutes after everything is up the daily maintenance task starts, off schedule, and begins a repair on the client for some unknown reason. After that it’s broken, nothing can be installed from SWC, the correct name in the upper right goes back to default, only two actions are available in the actions tab in the control panel.., until the next time the daily maintenance task runs which is usually sometime after midnight, then it’s fine, and everything works as expected. If I manually start the maintenance task it also repairs the broken client. The same task sequence works flawlessly for 2008R2. 2012 SP1 CU1. New deploys, redeploys, with install options, without install options, with patch, without patch, doesn’t matter, always happens for me with server 2012. Todd From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Fritzroy Guillot Sent: Friday, September 13, 2013 9:15 PM To: [email protected] <mailto:[email protected]> Cc: [email protected] <mailto:[email protected]> Subject: Re: [MDT-OSD] OSD Breaking CM12 Clients For the most part these are new builds, the one thing that we do is pre-create the computer account in AD and add them to various AD groups Sent from my iPhone Fritzroy Guillot On Sep 13, 2013, at 4:18 PM, "Jeff Poling" <[email protected] <mailto:[email protected]> > wrote: I am not sure about that error. . .perhaps someone else on the list has seen it; however, I've seen similar behavior when there are duplicate GUIDs in ConfigMgr for a PC. Have you validated there are no duplicates? Also, have you checked to make sure the client in question is Approved? Jeff On Fri, Sep 13, 2013 at 2:24 PM, Fritzroy Guillot <[email protected]> wrote: The only thing that stands out in those logs is the following line item Unable to get SMS_MPInformationEx.MP="<MP Server Name>" of [<MP Server Name>] from WMI due to error 0x80041002 That was located in the Location Service Log. We are currently not specifying any custom properties for the client installation out side of what I mention about the CU2 updates. Are Task Sequence we are running a numbers of steps from enabling the TPM chip and installing MBAM and installing drivers. Really nothing to fancy. -Fritzroy _____ Date: Fri, 13 Sep 2013 13:59:42 -0500 Subject: Re: [MDT-OSD] OSD Breaking CM12 Clients From: [email protected] <mailto:[email protected]> To: [email protected] <mailto:[email protected]> Is there anything of note in log files such as: LocationServices.log PolicyEvaluator.log ClientLocation.log ContentTransferManager.log DataTransferService.log Also, are you setting any custom properties for the installation of the client? I guess it might also help to know a bit about the steps in the TS. Jeff On Fri, Sep 13, 2013 at 1:31 PM, Fritzroy Guillot <[email protected] <mailto:[email protected]> > wrote: We have also tested running the task sequence without the CU2 update and seen varying results in regards to the client being fully installed. But for the most part the communication to determine what applications should show up in software center is taking way to long. -Fritzroy _____ Date: Fri, 13 Sep 2013 13:25:55 -0500 Subject: Re: [MDT-OSD] OSD Breaking CM12 Clients From: [email protected] <mailto:[email protected]> To: [email protected] <mailto:[email protected]> I have not seen this specifically, but one thing you could try would be to remove the CU2 patch step from the TS. See if the client responds better. If it does, then deploy the CU2 patch to a collection using the package that was installed (if you chose it) during the CU2 update. Jeff On Fri, Sep 13, 2013 at 1:15 PM, Fritzroy Guillot <[email protected] <mailto:[email protected]> > wrote: We have a strange issue that I was hoping someone could help us with. We are currently using MDT 2012 Integrated in CM12 for our OSD deployments. Here is the process: We run our OSD build which completes without any issues, Once the machine is on the network it then should talk to the CM12 server to pull down the policies and find the additional applications that should be installed through software center. Problem that we are seeing is that once the builds complete, it seems like the CM12 client is never fully installed. Some times we are seeing over a couple of hours before the CM12 client shows fully installed and is communicating with the CM12 server. That is when applications are showing up in the software center. We are concerned that we have a broken client because the OSD process. Couple of things to note, as part of our Task Sequence we are pushing out the CU2 patch. PATCH="%_SMSTSMDataPath%\OSD\CMP00257\CU2Patch\x64\configmgr2012ac-sp1-kb2854009-x64.msp" -Fritzroy
smime.p7s
Description: S/MIME cryptographic signature
