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
Oct 24, 20182 min read

Update package content locations during OSD

Updated: Oct 27, 2018

In our environment every client will start of on the same VLAN when performing a PXE boot.

And, when it does, it will build a list containing the locations of all the packages it will need , during the task sequence in question, and keep the list of those no matter what.

So what if the client changes IP, boundary, DNS domain or even VLAN, won’t the list be updated? No, it will not.


This was a problem for us.

Every client will start of on the Enterprise VLAN.

The Educational VLAN is for high school students, who also have local admin rights on their personal computer. We don’t want our “clever” students to be able to affect our Enterprise environment in any way so consequently the clients in the Educational VLAN won’t be able to reach the DP’s belonging to the Enterprise VLAN.


That told me we needed to have the DP’s of the Educational VLAN as fallback on the default boundary and make 3 types of packages:

1. Enterprise ->Ent DP’s

2. Educational ->Edu DP’s

3. Common ->All DP’s

Right?

Wrong.


Tried that.

In PXE phase the clients act kind of smart. They will ask the server which offered the PXE boot for the locations of the packages.

So common packages will always point to the Ent DP’s when performing PXE boot.

After changing VLAN, for the domain join, the OSD will therefore fail if a client on the Edu VLAN is needing a common package .


Don’t get me wrong, I’m sure of what I am describing is possible by only make packages of types 1 and 2, even if you include a refresh scenario from the Edu VLAN, making doublets of every package, windows image, driver and so on.


But I wanted to find a better way that didn’t require multiple packages with the same content and a solution which didn’t rely on the human factor.

Doing it wasn’t easy but explaining why was even harder.

Think that if you can find a use for the script you’ll understand why I did it. =)


In the TS, before the step "Setup Windows and ConfigMgr", I added a step which changes "_SMSTSMP" to the new MP. If you don't "Setup Windows and ConfigMgr" is the last thing you'll see in the logs on the site server, even if the TS continues.


After the steps mentioned above, make a step that runs the following script.




147 views0 comments

Comments

bottom of page