The idea behind OSD in Configuration Manager is automation. Right? We want to create a process to eliminate as many manual tasks as possible. Some companies have their technicians manually disable IPv6 on all adapters. Who wants to do all of that manual work when we can have it automated? My clients occasionally ask for a step in the OSD Task Sequence to disable IPv6. If you would like to disable IPv6 on all interfaces, you should do it in a way that is easily reversible on your client computers companywide. Here is how I did this for a recent client:
2) Create a new Application. Go to Software Library Workspace –> Application Management –> Applications. Right click and select “Create Application”.
3) In the Location box, type in the UNC path to the MSI. Click Next.
4) Because we used an MSI, the installation command line, uninstall command line, and Detection Method are all created for you. We’re not done yet. We will need to change these around. Click Next.
5) Change the name and the Installation program to what you see below. Click Next. Click Next. Click Close.
6) Click on your new Application in the console. Click on the Deployment Types tab at the bottom of the screen. Right click your Deployment Type and select Properties. Rename your Deployment Type.
7) Click on the Programs tab. Change your Uninstall program to the line you see below.
(With normal applications, you would use “msiexec /x”. But, these are separate MSIs for disable and enable. Both are executed as installs.)
8) We will now point the Detection Method to the registry key that these are adding or changing. Click on the Detection Method tab. Delete the clause that was created by the initial process. Add a new clause as seen below. Click OK twice.
9) Distribute your new Application to your Distribution Points.
10) Test it on a collection of test computers. Monitor the registry integer you see above to make sure it works. When IPv6 is disabled, the value will be “ffffffff”. When it’s enabled, the value will be “0”. You can verify that IPv6 is disabled by opening a command prompt and typing in “ipconfig /all”. After the install and reboot, there should be no IPv6 listed. NOTE: This does not take the check box out of the IPv6 in the connection properties. But, IPv6 is disabled.
11) Now, put it into your Task Sequence for OSD.
12) This Application can also be used to deploy to computers in your company. Just make sure to make it “Required” and Hide all Notification. Deploy it as “Install” to disable IPv6. When you need to enable it in the future, just deploy it as “Uninstall”.
It does require a reboot to take effect. But, the reboot is suppressed in the command line. This will not reboot your client computers as long as your command lines are the same as mine.
If you only want to disable certain components of IPv6 instead of totally disabling/enabling it, you can use this same process with any of the MSIs in this link.
Enjoy! Let me know if you have any questions in the comments.
In the Microsoft System Center Configuration Manager, there are multiple ways to add your clients to SCCM collections.
A common way is to go to a master collection and browse to the computer. Then, right click it and select Add Selected Items -> Add Selected Items to Existing Device Collection.
My preferred method is shorter and helps safeguard against adding an obsolete computer instead of the one you need to add. If you accidentally add an obsolete client to a collection that has an application deployed to it, you might be waiting a long time for that application to install. That can be frustrating.
Luckily, obsolete clients are much less frequent in 2012 than they were in 2007. But they do still happen. It just happened to me after a Windows XP to Windows 7 Side by Side migration.
Add clients to SCCM collections:
1) Browse to the collection you need to add a client to.
2) Right click the collection and select “Add Resources”.
3) Make sure “System Resource” is selected as the Resource type (it should be by default).
4) Type in the name (or part of the name) of the computer you want to add to this collection. Click Search.
5) If you have an obsolete computer in the database, it would also display in this search along with the valid client.
At this point, you would recognize that there might be a slight issue.
In some rare instances, you may need the inventory from that obsolete client. But, you should usually delete the obsolete client from the database. You can watch for obsolete clients by adding the “Obsolete” column to the collections.
6) Click the correct computer and then click Add. Click Ok.
7) Now, update the policy on your client to finish the deployment.
I’ve seen a lot of environments and the one typical commonality is that there simply was no planning or forethought put into where to store everything like source files, packages, downloads, etc. Chaos reigns and it ain’t pretty.
For all of my lab builds and production rollouts, I use a simple script to build up a nice, consistent folder structure that is easy to follow and enforce, eliminates ambiguity, and is simple. Note that in really large environments, the exact details I outline here may not apply, the principals do though – namely keeping it simple (stupid) and consistent.
One of the first things I notice in most of these environments is that they have multiple shared folders on the same system for the different items. Why? Why use three or five or whatever number of shared folders when one will suffice? I always create a single, top level folder called ConfigMgr (not SCCM) and share it out. Then, under this folder I create multiple sub-folders for all of the content required. This way, everything that is needed is easily found and backed up. This share could even be hosted by DFS and physically located on a non-ConfigMgr system (or multiple if you are using DFS).
Another common source of issues is simple organization and naming, particularly of package/application source files. This is key so that you actually know what’s in each folder, what package or application it corresponds to, and if it’s being used at all. I always use three-levels of sub-folders: vendor, application, version. For the version sub-folder, if its applicable, I always use the version number, architecture (x86 or x64), edition (like Pro Plus or Enterprise), and an indicator for App-V if that’s in use in the environment. You could use more sub-folders for these, but that’s usually overkill and unnecessary.
Permissions can get a little tricky — but just like King Burger, don’t get crazy with it. Best practice for shared folder permissions is to use Everyone Full or Read and let NTFS control access on a granular level. In this case, I use Everyone Full because ConfigMgr needs to write files to some of these directories and you as an administrator surely will want to also.
Here’s a snippet of the batch file I use to set up my typical hierarchy:
@echo off pushd %~dp0 echo Creating top-level Directory md ConfigMgr cd ConfigMgr net share ConfigMgr=%cd% /GRANT:Everyone,FULL echo Creating Sub-directories md Content md ContentSoftware md ContentUpdates md ContentDrivers md ContentApp-V md ContentOSD md ContentOSDBootImages md ContentOSDOSImages md ContentOSDOSInstall md ContentOSDMDTToolkit md ContentOSDMDTSettings md ContentOSDDrivers md ContentOSDMDTSettingsDeploy md InstallationUpdates md BootImageFiles md Captures md Hotfixes md Scripts md StateCapture md Tools md ToolsPSTools md Stuff md MDTLogs md Import md ImportDrivers
md ImportMOFs md ImportBaselines echo Setting permissions icacls Captures /grant %USERDOMAIN%_cmnaa:(OI)(CI)F icacls MDTLogs /grant %USERDOMAIN%_cmnaa:(OI)(CI)F icacls StateCapture /grant LocalService:(OI)(CI)F
And, here’s a PDF that shows my “typical” folder structure with a brief explanation of each and permissions I often assign (this doesn’t match completely with the batch file above as these are both just starting points).