simulacra75

It was the source path to the actual Language Packs that was incorrect in my case! Amazing what impetus a request for log files can make!

Yes, let clients at the VPN site access the MP across the WAN. They should only be querying the MP for policy, and get content from the local DP (i would suggest a local DP at that location). I have this exact type of setup and have locations with 500+ machines and it works fine. I do not know the threshold of when adding a local MP would become beneficial.

Tried the search feature? Maybe not, it's here

What speed is the VPN-connected site back to where the Primary Site is at the moment? I assume it's always connected

Hi there Seem to have a problem with Language Interface Packs and Windows 10 1607 in a Task Sequence deployment. I've followed the guide on this site and that part seems to work (at least partly). Date/Time is displayed in the language of the LIP I installed (Chinese Traditional) but if i launch Windows Explorer, for example, the menus and labels are all still in English. If, however, i run a Task Sequence that installs the OS in English and manually apply the LIP after the TS completes using DISM from a command line then Windows Explorer shows all labels and menus in Chinese Traditional (this is the desired outcome). Any ideas where i might be going wrong in my TS?

The log files indicates IIS 401 errors, "access denied" when attempting to download the OS image. Is your Network Access account set correctly?

I'm assuming you've installed KB3095113 and KB3159706 as part of your WSUS installation process?

Check that you do not have any GPO's in place that allow users to "Defer Updates". The ability to Defer updates has a direct impact on whether a Servicing Plan update is applicable to a machine or not.

If you have over 100 machines with this issue then it's likely you have a problem with your WSUS setup. Are you positive that your Software Update Point is installed and configured correctly on the Primary Site server? In relation to the log files for IIS. Each IIS website has a unique ID. This unique ID can be seen when you right click on a website in IIS and then select "Manage Wesbite", and then "Advanced Settings". A new dialog box should open and the unique ID is listed in the ID field. Let's just say that the ID is equal to "1234567890". The corresponding log files for this website would be normally located in c:\inetpub\logs\LogFiles\W3SVC1234567890\ So, in your case you need to find the unique ID of the "WSUS Administration" website in IIS on your Primary Site server. I would also suspect that re-imaging won't necessarily resolve your problem. If over 100 machines have the problem, then it's more likely that there aren't 100 machines with an issue, there's an issue on the backend infrastructure that's preventing these 100 machines from functioning correctly. Could be wrong though.

I'm not sure you have that exactly right. I have the 1703 updates in my own console, no good reason why they wouldn't be in someone else's. Something I did find out though, if there are any GPO settings for " Defer Updates" then this has a direct impact on whether client machines appear as having a servicing update "applicable" to them. I turned off the whole GPO settings in relation to this and a day later my clients appeared to have the Win 10 updates "applicable" to them. My 2 cents.

Okay, the error, 0x80240fff, is a catch-all, generic error. A full list of error codes and their meanings are available here (for future reference). What i would suggest moving forward is to; 1). Stop the wuauserv service on the client machine 2). Delete the contents of c:\windows\softwaredistribution on the client machine 3). Start the wuauserv service again on the client 4). Initiate a Software Updates Scan cycle from the control panel applet, just Run, control smscfgrc (quick way of opening the applet) 5). Monitor the Wuahandler.log file on the client and the IIS logs on the Primary Site that the client is a child of, usually located in c:\inetpub\logs\<IIIS-ID-OF-WSUS-WEBSITE>\

Have you checked the WUAHandler.log file on all 3 client machines? What does it have to say? Are each of the client machines correctly pointing to the CM12 WSUS server? (i'm assuming that you're using WSUS in CM12). What does the registry location, HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate show? Are your clients pointing to the WSUS server in CM12?

Arrghhh! I hate it when it's that simple! Shoot me now! It seems that it needs a minimum of the EFI partition in order to work (at least in the testing i've just carried out). Do you happen to use these EFI and MSR partitions for anything or are they just "empty"? A sincere thank you. Have a virtual pint in The Strand on me.

Title says it all really. Disk to setup as a GPT, UEFI boot drive. Task Sequence starts, image gets laid down. TS errors out with a "system partition not set" error in smsts.log. The partitioning step sets 2 separate partitions. I've attached screenshots of the partitioning steps. Anyone have any ideas? Probably some stupid mistake on my end.

On a related topic, i personally *hate* importing drivers into the Driver Packages node on the CM12 console. It's slow, it bloats the DB (in my opinion) unnecessarily. The method i have taken up is documented here in an earlier post by Achim. I love this method personally, your own mileage may vary however. Another method which i'm considering is outlined here.

Would it be possible that it's a GPO that's preventing the machines from receiving/activating the RC settings?

As a sanity check, run the below SQL against the SUSDB on each SUP. select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded =1 and Declined = 0

Hi there I have just read the list of deprecated features/operating systems for ConfigMgr 1702 and there's still something i'm not 100% clear on. All of our Primary Site servers are running Windows Server 2012 R2 (so that should be fine). However, some of our Primary Sites do have their SQL databases residing on "other" servers which are running Windows Server 2008 R2 (SQL itself is indeed 2012 on those servers though). The question i have is can i upgrade to 1702 with this infrastructure? Thanks

Yes, your thinking is correct. Windows PE will use whatever driver has been added (if any) up to the point where the OS gets installed and drivers get injected. After this point the NIC driver that's used is the Windows driver AFAIK. You ask is there a better way to install drivers? On a personal level, i believe there is and it completely bypasses the Auto Apply Drivers section of the Task Sequence. Here's what you do; 1). Download all the drivers for a given model of computer and create a package in CM12 (Not a drivers package, just a regular package). Let's say it's called Dell Latitude 7275 2). In the Apply Driver Packages section of your Task Sequence create a "Set Task Sequence Variable" - Name: Set %winrootdir% to C:\ - Task Sequence Variable: winrootdir - Value: C:\ Set a condition on the above to only run if the Folder called "C:\windows" exists 3). Create a Run Command Line step called, Apply Dell Latitude 7275 - Command Line: dism.exe /Image:%winrootdir% /Add-Driver /Driver:.\ /Recurse /ForceUnsigned - Tick the Package box and select the Package you created in step 1). 4). Put a condition to only run on Dell 7275 machines (WMI: select * from win32_computersystem where model like "Latitude 7275") That's it.

What NIC type is your VMware host using? If it's using VMXNET then you should change this to E1000. Furthermore, i have never been able to successfully PXE boot a VMware to install Windows 10 unless the Windows 10 host was set to do an EFI boot, not BIOS.

Well, i already have a single Task Sequence with the relevant OS WIM files referenced within it and each regional location is able to choose what OS language they wish to install. What i'm ultimately trying to achieve is not having to deploy a whole bunch of WIM files to Distribution Points where they're never going to be used. Currently i must distribute them to all OSD Distribution Points or else the TS fails because it cannot reference the content on a local DP. Given that each WIM file is about 6GB, it would make the back-end distribution of the WIM files much quicker if i only had to deploy the English WIM file to my European locations, for example. Hope that answers your question.

Take a look at, https://www.systemcenterdudes.com/sccm-1511-migration/

Don't mean to state the obvious but it's failing because it doesn't have a NIC driver. Can you check that the step where drivers get installed is not disabled?

Well, if the version of Office 2016 that you have deployed is the .MSI based installer then i don't think you're going to have much choice but run the installation of the new media. If you initially deployed Office 2016 Click-To-Run, then you can indeed "update" this to the latest version by downloading the most recent version and pointing your clients to this "source" as their update location. Hope that makes sense to you.

Hi there I apologise if this has been asked before but i cannot find anything specific to what i'm thinking. What i would like to do is only show a particular Task Sequence to a machine that PXE boots or USB boots from a particular location. Currently our TS's are deployed to the Unknown Computers collection and this works fine but i'd like to add some granularity to the whole process. For example, in Japan they only deploy the OS in Japanese so i'd prefer those folks to only "see" a Task Sequence of my choosing that only contains the Japanese OS. Likewise i would not want a European PXE boot to be able to see this Japanese TS. Does that make sense? I'd hope to avoid having my admins have to do any pre-import work, etc to get this to work. Ideally i want a PXE boot (or USB boot) in Japan to show one set of Task Sequences and the same PXE boot (or USB boot) in Europe to show an entirely different set of Task Sequences. Hopefully this isn't too confusing! Thanks Gerry