top of page

OUR PRECONDITIONS

  • The old network infrastructure, referred to as OldNet:
    Doesn’t support 802.1x.
    Two domains on different VLAN’s with a one way trust, referred to as Enterprise and Educational.
    The two domains have their own network infrastructure, different IP Helpers, DNS, DHCP and so on.

  • The new infrastructure, referred to as NewNet:
    802.1x is required using CISCO ISE and Layer 3 switches.
    Only one fallback net with its own IP range, common for both domains, which also supports WebAuth guest access.
    The two domains still have their own IP range, DHCP, DNS etc. but will use the same PXE-server since PXE boot is taking place on the fallback network.

  • Both the old and the new network infrastructure will be used to deploy Windows 10 x64 and Windows 7 x86.

  • MAB will not be used during OSD, the network team don’t want to spread a special OSD VLAN so clients will get an IP address according to its current location and only certificate-based authentication is allowed.

  • The task sequence needs to support both the new computer and refresh scenario as well as BIOS to UEFI conversion regardless of the currently installed operating system.
    The scripts used for managing 802.1x needs to support Windows 7 and its PowerShell version.

Search
Writer's picturesomeguy100
Nov 30, 20192 min read

Available TS's affecting Software Center Performance fix / (Run a hidden TS)

Updated: Dec 3, 2019

Edit 2019-12-03: Our pre-production client went live this Sunday. So this not working might have something to do with that and these new "_*"-Policy variables for programs which I havn't seen in 1810.


Edit 2019-12-02 : Do not use this. My understanding of the provisioning mode was that the client didn't use the policy at all during the OSD. That's not correct and therefore this will fail after the 2nd restart in FullOS at software installations.

(I only verified that the "state restore"-group was working, which it is.)


MS has given us a lot to be happy about with Software Center, especially if you compare it to what we had in SCCM 2007.

Another awesome thing that they’ve given us is the ability to run a TS as a step of another TS.


That being said, it’s far from perfect.

We love the fact that we’re able to create a module based OSD.

One main TS and sub TS’s that handles test versions of software, drivers etc before we go live and according to different OS versions on top of that.


But there’s a flaw in Software Center.

Software Center doesn’t know which programs/applications that are part of a TS and which that are not by default, it only sees the advertisement, which is available in either case.


So it needs to evaluate what to show. Why? How great would it be if users were able to install, e.g., a driver package, just because it is part of a deployed TS?


The problem with this is that it slows Software Center down just by having a “Reinstall your computer”-Sequence as available to the users.


Without our TS it takes ~8 secs to update the view of the applications tab.

With our TS available, it can take up to a minute to do the same.

I’m not talking about showing new software or how long it takes for them to show up, I’m talking about pushing F5 or scrolling down to show more…



Made a fix for it, which also can be used to trigger a new kind of hidden TS’s from the Software Center GUI.

Create a deployment of the TS that you want to hide, set availability to “Only Configuration manager clients” and put the available time to 10 years in to the future.




Create a package containing “Trigger-HiddenTS.ps1” and then create another TS with a “run powershell script step” with the DeploymentID of the hidden tasksequence as the value to “TSDeploymentID”.



If you also want the TS that triggers the OSD to be shown in the “operating systems” tab, create a dummy “Apply operating system” step and disable it.



Sidenote:

Will it be possible for the policy to override what we just did?

No, not according to my findings.


I've set the client policy to update every 3 mins (the lowest possible) and put a sleep of 9 mins in the script between changing the time of the schedule and triggering the TS.

The WMI instances are still the same.


244 views0 comments

Comments

bottom of page