Enabling DHCP using PowerShell is very easy and can be accomplished in three lines of code. Yet for some reason many other online guides show the long way around.
I previously posted about how to set static IP’s using PowerShell. This script to enable DHCP can be a complementary program inside an SCCM package to configure IP addresses. That way, you can have an SCCM program to deploy a static IP and then another program to reset it back to DHCP, and both of these programs can be inside one package.
Alternatively, this script can be used as an Uninstall method if setting static IP’s using an application in SCCM, with a modified version of my network adapter configuration detection method script as the application detection method.
Either way, here is the short and simple script, with a log file output designed to add on to the previously mentioned Static IP script’s logs if they exist:
If your organization has computer labs which require static IP addresses, here is a very easy method to deploy static IP’s to each lab. Most labs will have some sort of numbering scheme as part of the computer name. We can take advantage of this in order to transform the computer number into an IP address.
In my example, the computer number is at the end of the computer name. I am going to use PowerShell to calculate the new IP address for each computer, apply the new network configuration, register the new settings, and output a log file. Here is the script:
I wrote this script to check for updates to some common software used in my organization. In order to do so, the script uses PowerShell to crawl the website of each piece of software so that it can get the software version number and download link. The script compares the version of the software it found online to the version it found in the local folder inside the script directory. If the version online is newer, it downloads the file and renames it to a nice format including the version number. The software (64-bit where available) crawled for download is:
- Google Chrome
- Mozilla Firefox
- Mozilla Firefox ESR
- Adobe Flash Player ActiveX
- Adobe Flash Player NPAPI Plugin
- VLC Media Player
I figured this script would be a good example to share because it uses a few different methods to find the information it needs on each publisher’s website. Some people can find these examples helpful to modify the code to crawl for something else. In the case of Adobe Flash Player for enterprise distribution, the website requires a login, so I just left the script to check the version and then open a browser window going to the login screen so that the user can manually download the MSI files. Since the Adobe enterprise distribution license says the download link cannot be shared, I have edited it out of the script, so you will need to replace it yourself if you want to use this function. Just search for all instances of “https://INSERT-ADOBE-DISTRIBUTION-LINK-HERE” and replace it with the URL you received from Adobe.
I split this script into functions, with a function to download the software and a separate function to crawl the website for each piece of software. Inside of each crawl function, I split the variables and crawl methods that need modification. This also means that you can remove the last part of the script after line 315 if you would rather use the script to manually call each function using the PowerShell console in order to check for just one piece of software.
Again, this script is very application-specific, so unless you need to check for updates and download this specific set of software, you will need to modify the script for whatever software you need. Use it as a very broad example of crawling the web with PowerShell. There are many different ways to do this, and I’m sure some might be better, but this way works exactly as I need it to for my specific use case. And of course if a website for a particular piece of software changes, the crawl function for that software will break, but there’s no way around that with web crawling.
Here is the required directory structure for this specific set of software:
And here is the full PowerShell script:
I wrote this script in order to extract MSP files from CAB files. The purpose of this in my case was to get Office updates that already existed in SCCM and to put their MSP files into the Office installation folder’s “updates” directory in order to have the updates automatically installed when Office is installed.
There are a few scripts online that do this already, but they are much more complicated since they dig in to the SCCM database and download the CAB files from the management point themselves, among other unnecessary (in my case) tasks. I wanted a simpler script that I could run on my own machine rather than the SCCM server for security reasons, so I came up with this PowerShell script that does just that, including renaming the files to match their KB numbers.
The script requires an “msp” folder and an “updates” folder to reside in the same directory as the script. Since this script is run locally, you need to have the CAB files already on your computer. The CAB files from SCCM do not need to be moved out of their respective folders – you can simply copy them as-is from your SCCM updates folder. This means your “updates” folder in the script directory can have folders inside of it, and those folders will have the CAB files. Once complete, the extracted MSP files will all be together in the “msp” folder, ready to copy to your Office installation’s “updates” directory.
Here is the script:
This very simple PowerShell script can be used to set these options:
- DNS Suffix for this connection
- Register this connection’s addresses in DNS
- Use this connection’s DNS suffix in DNS registration
I’ve seen many questions online on how to use a script to mark the two checkboxes in this “Advanced TCP/IP Settings” window.
So here is the very short and simple PowerShell script:
I wrote this PowerShell script for use as an application detection method inside an SCCM application. The SCCM application would set the network adapter configuration if it is not currently configured properly. This company has a special DNS setup for SCCM clients that is different than for non-SCCM clients. Here is the PowerShell code:
Contrary to popular belief, Dell’s CCTK tools (now called Dell Command Configure) do not have to be injected into WinPE in order to make changes to the BIOS during the WinPE phase of a task sequence. This applies both to SCCM and MDT task sequences.
The benefit to not injecting CCTK into WinPE is that it can be updated and maintained without having to rebuild boot images.
To do this, simply create a package in SCCM with the required CCTK files, or in MDT create a folder in the deployment share. Do not create a program for this package. The components required are:
Next, create a task sequence that references the package you created. The first step will be to install HAPI, which can be done inside of WinPE. Since WinPE runs like a “live-cd” no changes will be persistent. Your task sequence should look like this:
In this example I am setting a wake-up time in the BIOS. Below are my commands for each of these steps in the task sequence: