ranmojo

After I have a stable task sequence, it can start at random when changes are made to the sequence. Then it will fail consistently until I play around with the task order. This is with MDT 2013 Update 2.

I had similar issues, the BDE recovery key would inconsistently be written to AD (usually not at all). You were _very close_ with the link you pasted. Yes, it has manual steps in the discussion but there is a lead-up to an automated script at the bottom, it's a link - look carefully for it below the authors' signatures: "BDEAdBackup.vbs" I've tried this script by inserting it as a new command line task in my sequence toward the very bottom, after I've already enabled BitLocker. If you do it too fast there may not be key data ready to write to AD. In my case, it solved the issue. I usually kick it off by running: cscript.exe %SCRIPTROOT%\Custom\BDEAdBackup.vbs Original blog post with that script link is: https://blogs.technet.microsoft.com/askcore/2010/04/06/how-to-backup-recovery-information-in-ad-after-bitlocker-is-turned-on-in-windows-7/ Your mileage may vary. Good luck.

I have an issue that follows me around and pops up at arbitrary times. I can have a task sequence working great for months, then make some changes and get this issue to "pop" out of nowhere. The issue is that the task sequence will try to start over on itself for no reason and it can always be narrowed to a custom script or app install (but not always the same one). The error in the smsts log is "Another task sequence wizard is already running." In the smsts.log the behavior is that after something executes, all of a sudden TSMBootStrap.exe fires up out of nowhere, ruining the in-flight sequence. Here's an excerpt of the failure from smsts.log. For context, all this batch script does is run RunDLL32.exe and load some registry keys from an .inf file. I know this is but one way to load registry keys, it happens to be a holdover from some previous deployments. Point is, it works fine, and just happens to be "the one" that caused an issue this time. Other scripts AND app installs arbitrarily caused this in the past, and I don't know what the trigger is. Simply moving the script or app to a different step in the sequence is often enough to get the behavior to stop. Note that there is no script-induced reboot here, I know that can cause issues. Expand a string: cmd.exe /c %SCRIPTROOT%\Registry\Set-ClientRegistry.bat TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) Expand a string: TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) Start executing the command line: cmd.exe /c %SCRIPTROOT%\Registry\Set-ClientRegistry.bat TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) !--------------------------------------------------------------------------------------------! TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) Expand a string: WinPEandFullOS TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) Executing command line: cmd.exe /c %SCRIPTROOT%\Registry\Set-ClientRegistry.bat TSManager 12/30/2016 2:59:57 PM 5240 (0x1478) ==============================[ TSMBootStrap.exe ]============================== TSMBootstrap 12/30/2016 3:02:49 PM 4808 (0x12C8) Command line: "C:\MININT\Tools\X64\TsmBootstrap.exe" /env:SAStart TSMBootstrap 12/30/2016 3:02:49 PM 4808 (0x12C8) Current OS version is 10.0.14393.0 TSMBootstrap 12/30/2016 3:02:49 PM 4808 (0x12C8) Another Task Sequence Wizard is already running. Wait for this to complete and try again. TSMBootstrap 12/30/2016 3:02:49 PM 4808 (0x12C8) Exiting with return code 0x80004005 TSMBootstrap 12/30/2016 3:10:52 PM 4808 (0x12C8) ==========[ TsProgressUI started in process 1828 ]========== TsProgressUI 12/30/2016 3:10:52 PM 3556 (0x0DE4) Unregistering COM classes TsProgressUI 12/30/2016 3:10:52 PM 3556 (0x0DE4) Shutdown complete. TsProgressUI 12/30/2016 3:10:52 PM 3556 (0x0DE4) See what happened there? Something caused TSMBootStrap to spring up out of nowhere and ruined the sequence, which had many steps remaining. (I am not certain what is going on during the nearly 3 minutes after batch file execution attempt - that is a mystery, the file only takes a few seconds to run). The .bat file never got to finish, and never made a return code. When things are working normally I will get a Return Code 0 from the batch file execution. The actual return code here - 0x80004005 - Access Denied - is from TSMBootStrap, trying to access something and throwing this error presumably because the task sequence is already running! Thanks for reading!

I made two changes and then the client registered... 1. I removed a SRV record for _MSSMS_MP_<SITE>.domain.com that referred to port 80, and left only the record for port 443 since I am using HTTPS for the entire site, internal and external. 2. I setup a network access account in the site config. If this has any impact it implies the net access account is used for MP activity not just DP content? But it may be #1 that ended up solving the issue.

So I managed to install the SCCM client on a workgroup computer also running server core - at least it looked successful. But the client has not registered with the site, and cannot locate the site if I try to punch it into the Config Manager control panel applet on the Site tab. (Error message: "Configuration Manager did not find a site to manage this client.") Full disclosure: I am using a PKI setup and a client certificate. The certificate is successfully installed. The root and intermediate certificates are installed in the proper computer stores. I used this install syntax: ccmsetup.exe /usepkicert /noservice /skipprereq:silverlight.exe SMSMP=https://myserver.domain.comSMSSITECODE=PS1 DNSSUFFIX=domain.com Both ccmsetup and client.msi logs returned successful installs -- return code "0" at the end. But the client doesn't show up in my site... and the CCM control panel Actions tab only has the two initial items in it, User & Machine policy refresh. How can I figure out what is preventing the client from fully communicating with the site? I also noticed the General tab makes no mention of PKI like normal clients do, that I've installed elsewhere successfully using certificates. The client certificate is "none" on this machine. But CCM client does not install if it cannot find a suitable certificate, so how could it install but say client cert = none? In LocationServices.log I can see entries that there is access denied 0x80004005 failed to send information Location Request Message to <MP server name>. Hmm.

Bueller? Wow I stumped the audience.

Hello everyone, I am setting up IBCM and am looking at the DP cert requirements. In the TechNet documentation and walk throughs, this cert is often configured for auto enrollment from ADCS with private key marked exportable. There's no mention of Subject Alternative Names... but my spidey sense is that I need them to share the cert properly. My question is, if I have a primary site server and an Internet site server (for IBCM), would I need to request this cert with SANs? Would the SANs need to include the internal server name, the external server name, AND the Internet FQDN name? And then I would install this cert on both servers? (Update) I failed slightly at reading comprehension, a different TechNet page than I originally reviewed DOES at least say this about the DP cert: https://technet.microsoft.com/en-us/library/gg699362.aspx "There are no specific requirements for the certificate Subject or Subject Alternative Name (SAN), and you can use the same certificate for multiple distribution points. However, we recommend a different certificate for each distribution point." Interesting. So I can share the cert, but they suggest not to. And the SAN doesn't seem to matter. But is this really true? Anybody who's implemented can verify one way or the other how they did it? Thanks.

UPDATE: I just made a breakthrough and I'm starting to understand what is happening here. For my 64-bit collection, I am using a limiting collection I created called "All Windows Computers" which is based on the query System Resource.Operating System Name and Version is like "%Microsoft Windows%". The membership of this limiting collection was up to date. Regardless, I forced a manual update, and then, interestingly, my 64-bit colleciton "woke up" and jumped right up to the number I expected, which is 102. So at least I can fix this with some prodding, but I'm still confused as to the delay on the 64-bit collection. I've told my 'All Windows Computers' limiting collection to perform incremental updates AND a full update every 3 days, and it has been keeping regularly up to date. There's something goofy with the interaction between the two collections.

My first post in forums! Thanks to everyone who contributes here, what a great resource. I am getting up to speed with SCCM 2012 R2. I recently installed clients using Client Push on over 100 servers. I have a pair of collections I created for ease of deploying client hotfixes. The collections are based on a query for Processor.Address Width = 64 (64-bit AMD64 client machines) and another collection for Processor.Address Width = 32 (32-bit x86 client machines). OK so that was easy, and clients have *started* to populate the collection, but I have 100+ 64-bit clients and only 38 of them are in my 64-bit collection. Everyday, the number ticks upward by about a dozen clients. I don't understand this. My membership rules on the collection are set for Use incremental updates AND also run a full update every 5 days. Also, I have manually right clicked the collection and selected "Update Membership" and yet, nothing happens. I go off and do some other work, come back the next day, and the number has gone up magically... but is still far short of my 100+ clients in total that I expect to be in there. I was thinking this was related to the Hardware Scan - I realize for freshly deployed clients it takes some time for the initial scan, so that the Processor.AddressWidth information is available. BUT I don't believe this to be an issue, because right now all my clients have sent at least one round of Hardware Scan data back to SCCM and yet, only 38 of 100+ are in my 64-bit collection. I am missing something here... I don't know what it is. More info: I created a query in the Queries folder for Processor.Address Width = 64 and I do return well over 100 items, like I'd expect. So the data is definitely there.