YPCC

Got fed up with this issue. About 20% of our machines running 32bit windows 7 had this issue and wouldn't complete a update scan which meant they hadn't been patched since 2015. They were showing as compliant in SCCM, HUGHE FLAW!!! In the I downloaded the windows 7 convenience rollup and deployed it as a package. This brought the OS relatively up to date, from there on the machines would scan for updates successfully.

How did you test it? It has to be run with the Task sequence environment (New-Object -ComObject Microsoft.SMS.TSEnvironment), so if all you did was run the VBS in windows that it wouldn't work.

Your using a unc path. Sccm packages cannot access these unless you add a line before mapping the location. Try this in your script.... ..... Net use \\Domain.net\sccm$\Source\Desktop_R3 xcopy /s \\Domain.net\sccm$\Source\Desktop_R3\*.* "C:\Program Files (x86)\Desktop\" /Y ......

Yes, override that by creating a GPO which has windows updates enabled from MS. Also check client settings, create a new setting for desktops and turn off the software update settings.

Have seen the collections issue and frankly a reboot has always sorted it for me. Ive since upgraded to sccm 1602 and issue doesnt occur. Regarding PXE, the new boot image you have assigned, have you set the option of "enable this image to run from pxe dp" in the boot image properties? Also what happen if you remove the boot image from the DP. Does sccm try use a alternative or fail to load pxe completely.

Id imagine not much changes in the way of deployment. Instead of multiple patches, youll get 1 patch. If you need to roll back, the whole patch has to come off. Not sure how a ADR will react though.

trying to modify a value in the 32-bit section of the Software hive. Not a problem, have you tried doing this to see if it works. I usually use a "Reg add" command to put reg keys into a machine. You can force "reg Add" to place it in the wow6432 hive. By default it places it in the 64bit hive, but using a "/reg:64" will ensure the entries goes into the 32bit hive trying to modify a value specific to a user correct. This one is tricky but heres one way to do this: 1 - Create a "Application" or "Package" that runs for the user (but with administrative rights), I had a scenario where i needed to send out a reg key to HKCU so created a Application, which applies a batch file. The application is set to install for user therefore works for every user who logs onto the machine (as the application detection method checks HKCU if the key exists, therefore anybody who logs on will get the key if they dont already have it) You could also use Orca to edit the MSI file and insert those regkeys into it, although thats a bit more involving.

Yes computer is named shortly after. Instead use the osd computer name variable as your condition. For example...So when you start and decide you want to name the server "cust12345", you condition would be... IF task sequence variable %osdcomptername% is like "cust%" etc

As Garth says.... and of they are added back on the next ADSys discovery and you have auto client push enabled, they will become clients again. So be mindful of this. Alternative is leave the sccm client on them and just block them in sccm. That way nothing can get deployed to them.

Interesting it works ok on the server. Try this... install a clean windows O/S on a VM and install the console on that. Does it work? Perhaps you have something installed on the clients that are causing this bug? Process of elimination i suppose. Any policies (GPOs) interfering? Firewall, antivirus, etc

No probs, but the question here is how will you determine what domain a server goes to? If you opt to have a choice of domain during the task sequence using the UDI wizard then its simple. You use the UDI designer and add both domains. If however you are not using UDI how will you program the task sequence to determine which domain the server should go to? An example of how to do this would be based on computername as you mentioned. So if a run the task sequence and set my computername to 123ABC then i can put a condition on the 1st "apply network settings" saying if computername is like "123%" then join to domain A. Then on my 2nd "Apply network settings" step i add a condition saying if computername is like "456%" then join to domain B. See what i mean?

Heres how we do it: - Have a software update group that contains a "baseline" of patches. This means patches that are installed on all servers in the estate. So when a new server is introduced into the environment, the "baseline" will ensure that new server is brought into line with all the other servers In your case, if you have 4 different collections, with various servers, why not just create another single collection that contains all your servers and deploy the baseline to that. Furhtermore, do you have any patching mechanism in place for new server that are bought online at all? For example in my organisation, when a new server is created and added into SCCM, we add the server to a collection that has server patches deployed to it. We leave it in that collection for 24hours so it takes all the patches, we then remove it from the collection and pass the server over to the business owner. You could automate all of this with powershell (we have using VmWare powercli and sccm powershell cmdlets)

You can simply add another "apply network settings" step and attach a condition to it (and your original step) If condition A is successful it joins dommain A. If condition B is successful it joins domain B

Google sccm smsdprov.mof... youll see some users have had issues with the WMI and had to run mofcomp.exe smsdprov.mof to correct ths WMI. worth a try.

^ as above Create a test collection, add a test machine, deploy patches, open a 4-5 hour maint window during your working hours then visually monitor what happens on the client after its installed updates. Are the logs indicating any failed at attempts to reboot. Or is it simply that your reboot countdown setting is so large that that it overlaps the next maint windows, thus never allowing your clients to reboot.

yes, happened to me once. Setup a patch deployment to a few servers, a maintenance window was created to allow patching to take place and so servers can be rebooted. Patching went past the maintenance window meaning the servers didnt get the reboot they needed first time time. Next time the maintenance window opened, servers automatically rebooted. Moral of the story - be careful when using "recurring" maintenance windows unless you allow plenty of time for a server to get patched the first time round.

Also you need to check client side logs on a working machine vs non working machine. Anything that stands out? Unfortunately at this stage without further info it could be anything at fault. One of the logs might allow you to narrow down the issue. Are the inactive clients sending a policy request to sccm? Can they connect to your sccm server via ports 80/443/10123/8530(8531 if https wsus)? What if you take a clean window image and install the agent, does it work? Considering some of your machines are working fine, there might something in common on the non-working machines.

Not convinced ths is boundary related. I often find clients not in my boundary range but can still manage them (just not deploy content unless a fallback dp is used) Id consider reinstalling your management point.

Thats right, this should get you going https://www.windows-noob.com/forums/topic/5131-using-sccm-2012-rc-in-a-lab-part-16-integrating-mdt-with-configuration-manager-2012/

if its installed and integration enabled, you now need to create a MDT Task Sequence. Forget your old task sequence. When creating your new "MDT Task Sequence", follow the wizard, it ask to to create 3 packages, MDT Settings, MDT Toolkit and USMT. Keep following the wizard, when done you'll have a new task sequence. Open this and youll see all the steps in there.

In order to replicate what is being done in that URL, you will need to install MDT onto your sccm server and enable MDT integration. Then from within SCCM, you need to create a "MDT Task Sequence". This will give you all the packages you need (MDT gather, toolkit, etc). If you've never done this before have a quick google. Installing and integrating MDT into SCCM is a piece of cake. Understanding and making use of a MDT task sequence requires a bit more reading up.

Deploy a sccm agent (ccmsetup), before a users logs in: - Do you have a old sccm already? If so, create a package/application that contains the new ccmsetup.exe and deploy it out to existing computers using your old sccm. Ensure you set to run "only when no user is logged on" - Or maybe you can use group policy installation and install the agent that way, im pretty sure that installs the agent before users logs in Deploy a application before a users logs in: Deploy a application but set it so it only deploys when "no users is logged on". You can also create a package/program and set it to run at logoff/at logon Deploy updates before a users logs in: Not sure if you can do it exactly before logon but maybe deploy updates out of hours so they install first thing or ask your users to leave the computers online overnight and deploy updates overnight.

Ahh. You have software update client installation enabled. Happened to me to. I made a GPO change to point all my servers to my new sccm server, only to reealise the client had gone out to them all.

Automatic client push. Is that enabled?

>>> C:\Windows\System32\WUSA.exe If i remember correctly, there is a WUSA.exe is the SYSWOW64 folder as well, you may need to call on this in order to uninstall the hotfix. The easiest way to test is simply try your command manually on a machine, that will confirm if your syntax is correct or not. If the hotfix is removed when you run the command manually on a machine then at least you're half way there. You then only need to worry about calling the correct WUSA