Setting a fixed IP Address during the MDT task sequences has always been ugly. It’s an area that I believe needs to be revisited by Microsoft.
- I don’t like the concept behind the “Apply Network Settings” task action. I don’t find it dynamic enough. In my opinion it’s too cumbersome and involved.
- The old “NICSettings_Definition_ENU.xml” custom pane no longer works from MDT 2012 and above as pointed out by a commenter on Michael Niehaus article about Customizing Wizards with MDT 2012.
- I don’t like the way the ZTINicUtility.vbs and ZTINICConfig.wsf scripts have been constructed. Too messy and too hard to follow. I appreciate that these have ended up the way they are over time, but a fresh start would be my recommendation.
I just found that everything out of the box was too messy and static. There are a couple of different blogs by others on this, but they also seemed quite awkward.
Of course if you’re looking to automate as much as possible, which is what I strive for, then some back-end apps require a fixed/static IP address set before they’re installed. Sure you can reserve addresses in DHCP, but that’s a management touch point I wanted to avoid. I prefer to allocate in the design and build out based on that.
I wanted something slick and simple so I created my own.
The following screen shot is what the wizard first looks like when launched.
The cool thing here is that when you select the “Use Static IP Settings” radio button, it automatically populates the required fields from the current adapter settings. This assists the person initiating the deployment because all they typically need to do is change the IP Address.
As you can see this version of the script allows you to set 4 values:
- IP Address
- Subnet Mask
- Default Gateway
- DNS Server Search Order
Regardless of whether or not you select DHCP or Static IP the script is hard coded to:
- Disable NetBIOS over TCP/IP, which in this day and age should be a best practice. It should also be the Operating System default. Are you listening Microsoft?
- Enable the “Register this connection’s address in DNS”, which is default.
- Disable the “Use this connection’s addresses in DNS”, which is default.
I’m actually reusing 6 existing task sequence variables and creating 1 new one:
- OSDAdapterCount
- OSDAdapter0EnableDHCP
- OSDAdapter0IPAddressList
- OSDAdapter0SubnetMask
- OSDAdapter0Gateways
- OSDAdapter0DNSServerList
- SkipNetworkSettings
So to implement it simply download the following 3 files, remove the “_.txt” extension, and place them in the %SCRIPTROOT% (Scripts) folder of your deployment share.
- DeployWiz_NICSettings.xml (1742 downloads)
- DeployWiz_NICSettings.vbs (1635 downloads)
- Set-IPV4Address.ps1 (1797 downloads)
Edit the “DeployWiz_Definition_ENU.xml” and add the following lines after the DeployWiz_ComputerName.xml pane has been added.
<Pane id="NICSettings" reference="DeployWiz_NICSettings.xml">
<Condition><![CDATA[UCASE(Property("SkipNetworkSettings"))<>"YES" ]]></Condition>
</Pane>
The condition means that the pane will not show if the SkipNetworkSettings is set to YES. Hence the new variable.
So now we modify the CustomSettings.ini
[Settings] ; Add SkipNetworkSettings as a new property Properties=SkipNetworkSettings [Default] ; NIC Settings ; If you set SkipNetworkSettings to YES, either remove/disable the Set-IPV4Address.ps1 PowerShell ; script from/in the Task Sequence or set the OSDAdapterCount=1 and OSDAdapter0EnableDHCP=TRUE in ; the CustomerSettings.ini. This ensures these are no errors during the build process. SkipNetworkSettings=NO ;OSDAdapterCount=1 ;OSDAdapter0EnableDHCP=TRUE
All that’s left to do is to add a “Run PowerShell Script” action to run the “%SCRIPTROOT%\Set-IPV4Address.ps1” PowerShell script. You can place this action where ever you think it’s appropriate in your sequence. The following screen shot shows where I place it for most builds. The example I’m showing is the top half of my sequence for building Citrix Provisioning Services servers.
I wrote the Set-IPV4Address.ps1 PowerShell script so that it can be run independently and used for other purposes, so it’s quite a versatile script. It’s fully documented throughout.
I will build on this as I get time, but please let me know if there is anything you feel I haven’t considered or if there is something you would like added.
Perhaps Microsoft will like what I’ve done and integrate my code with the next release of MDT 🙂
Enjoy!
Jeremy Saunders
Latest posts by Jeremy Saunders (see all)
- Best Practice for the Active Setup StubPath value - September 25, 2023
- User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
- Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023