Leading on from my other posts about creating device and user collections, in my environment I need to manage multiple domains so I thought I’d do a quick post on some of the prerequisites and some tips.  All these things should make your life a little easier and ensure errors are kept to a minimum.

Trust Relationship
Does a trust exist between your domain and the secondary domain you wish to manage?  If not create one.  If this involves setting up a Branch-Office VPN or WAN, speak to your infrastructure team and ensure both your network and the network that contains the other domain(s) have some way of routing to each other.  Every situation and infrastructure setup can present different constraints so I’m not going to go in to great detail on this one but here are a couple of links to get you started:

http://bit.ly/1IdfutP– Forest Trust Checklist
http://bit.ly/1PdgvEK– Creating a Forest Trust

Discovery (AD Sites and IP Subnets)
If you don’t set up your site and IP subnets properly when you first set up your domain and you leave everything as default then you unfortunately get the default name for your AD Site which is Default-First-Site-Name.  You’ll get issues discovering AD sites within ConfigMgr if all of your sites are named like this so probably a good idea to name your sites uniquely.   In addition make sure you have your IP Subnets set up for each AD site.  These will then all pull in nice and easy through discovery as long as you have your accounts setup properly so the account has the correct access.  To examine your discovery settings look here Administration \ Overview \ Hierarchy Configuration \ Discovery Methods from within the ConfigMgr Console and ensure the correct settings are in place for the discovery methods you wish to use.

http://bit.ly/1IkkUO9– Article on renaming AD Sites using PowerShell if you have multiple sites to rename like myself.  I wrote a script for doing this prompting me for each name.

Extending the AD Schema
I can see no reason why you shouldn’t extend the AD Schema but that may be because I haven’t come across a valid reason not to in my working life.  You can extend the schema on each of your domains by running the extadsch.exe  from the BIN\X64 folder on the root of your ConfigMgr disk or ISO.  You’ll then get a log file written to the root of C:\ which will tell you whether or not the process was successful.  Check this log before moving on.

System Management Container
Adding a System Management container and/or changing the permissions is advisable also.  You can use AD Users and Computer if you wish, as long as you have the Advanced Features switched on.  From the root of AD navigate through System \ System Management right click and select Properties.  On the Security tab ensure your ConfigMgr server (or servers group) have full permissions on the container.  Job done.

Client Push
I did a previous post on Client Push methods but once the above is in place your client push should now work a lot smoother either from the console or via any of the other methods.

Ref post: http://bit.ly/1EAKyAp

Check Site Systems & Components
Last but not least, check your site systems.  Navigate to Monitoring \ Overview \ System Status \ Site Status and check all of the components have a green tick and are OK.   Then look at Monitoring \ Overview \ System Status \ Component Status and check those are all working just fine working through any errors or warnings.  Personally I dread looking in here as there always seems to be some issue that crops up but if you keep on top of this you’ll soon have a streamlined slick system in place

I hope this was useful to you.

Jonathan.

I was recently tasked with removing Sophos Antivirus in favour of System Center Endpoint Protection (hereafter referred to as SCEP) using System Centre Configuration Manager (hereafter referred to as ConfigMgr).  I was hoping it could simply be deployed and that when SCEP installs it would automatically remove Sophos.  Unfortunately Sophos isn’t on the list of supported antivirus installations for auto-uninstall so I had to go about it a slightly different way.  Here is how I did it.

Preparation
First I did some research on SCEP and ConfigMgr clients and discovered that when pushing out Endpoint Protection the following Antivirus products are supported for uninstall:

Symantec AntiVirus Corporate Edition version 10
Symantec Endpoint Protection version 11
Symantec Endpoint Protection Small Business Edition version 12
McAfee VirusScan Enterprise version 8
Trend Micro OfficeScan
Microsoft Forefront Codename Stirling Beta 2
Microsoft Forefront Codename Stirling Beta 3
Microsoft Forefront Client Security v1
Microsoft Security Essentials v1
Microsoft Security Essentials 2010
Microsoft Forefront Endpoint Protection 2010
Microsoft Security Center Online v1

This presented a problem as Sophos is not on the list so it looks like I’ll have to uninstall Sophos using a script.

Sophos Setup
Sophos is normally pushed out from a management console.  It can be installed on your workstations in a variety of ways.  We have some settings pushed out via group policy on our domains with a batch file script that checks to see if Sophos is installed by testing to see if a folder exists and if not, pulling the installation msi from a shared folder.  This first thing I wanted to do was to unlink this group policy we’d made.  This will ensure that when I deploy SCEP from ConfigMgr, Sophos will not forcefully install on the next reboot and undo my work.  Once that’s done I need to do some testing on some VMs.  First I built two VMs, one with Windows 7 and one with Windows 10.  I manually add them onto the domain and install Sophos.  Next I create a checkpoint so that we have a point to refer back to should our test not be successful.

Preparing & Testing Uninstall Script
Sophos comes with a few services and a couple of programs to uninstall.  First lets create a few lines of code that will stop the services.   
Here is the batch file commands I found by searching around the web:

   1: net stop "Sophos AutoUpdate Service"

   2: net stop "Sophos Agent"

   3: net stop "SAVService"

   4: net stop "SAVAdminService"

   5: net stop "Sophos Message Router"

   6: net stop "Sophos Web Control Service"

   7: net stop "swi_service"

   8: net stop "swi_update"

Converted to PowerShell

   1: Get-Service | Where-Object {$_.DisplayName -Like "Sophos*"} | Stop-Service

Not all of these services will exist or be running, this just covers everything off.  Once the services are stopped, the Sophos knowledgebase article states you must uninstall elements of Sophos in a particular order like so:

1. Sophos Patch Agent
2. Sophos Compliance Agent
3. Sophos Remote Management System
4. Sophos Client Firewall
5. Sophos Anti-Virus
6. Sophos AutoUpdate

You can explore the following registry key to locate your uninstall commands

32bit Machines
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
64 Bit Machines.  Note: On a 64-bit computer you will need to check both the key above and the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Under these keys you will see a folder structure, each folder contains a different program and details about it you need to scroll through them all in order to find the ones related to Sophos and extract the uninstall command:

Take note of the DisplayName and the UninstallString you’ll notice the uninstall command, in this case MsiExec.exe /X{15C418EB-7675-42be-B2B3-281952DA014D}, will need extra switches on the end to make it a silent command.  I have added /qn REBOOT=SUPPRESS /PASSIVE to each one I found

Once you have them all ready you’re ready to create your script.   Create it so that the first section of the script stops all the services and the second part uninstalls the program in the order specified above.  Run this on your test VM and study the results.  Are all the programs uninstalled?  Are all the services removed?  If not why not?  Go back to the top and see if there’s something you missed.

Folder Condition
Supposing all of the above works properly in the test phase you may wish to now add some form of try/catch to your script to create a conditional folder which will be used in the ConfigMgr deployment.  If my script completes successfully and Sophos is removed I have built in that my script will create the folder “C:\Windows\Logs\SophosRemoved”.  You must be careful not to create this folder unless everything worked, you will see why in the next step.

ConfigMgr
I added my script into ConfigMgr as an application.  The idea being I will deploy this application to clients silently, making it required which will essentially remove Sophos.  In the applications section I have a scripts folder so I browse to Software Library \ Overview \ Application Management \ Applications \ Scripts and create a new application..

I select “Manually specify the application information” then give it a name.

I don’t need to specify an Application Catalog entry, so I click Next but I will specify a deployment type by clicking on Add…

Again I will select to “Manually specify the deployment type information”, click Next and then give it a name.

I will specify the network path location of my script and the command line to run it in the boxes highlighted and click Next.  Next I will need to specify a clause for installation.  In this instance I will set it to be the folder “SophosRemoved” I talked about earlier.  What will happen is the application will check for this folder before running.  If it exists it will not run.  You are required to have this clause and it doesn’t have to be a folder it could be a log file or anything you want.  As long as its properly built into your script to be created only if the script (or application) runs successfully.

I will specify some conditions for the clause and then select some for the user experience.   In my case I want it to be hidden from the user as I don’t want them knowing the AV is changing they don’t need to be bothered with that.  The next two panes in the wizard ask you to specify and hardware requirement needed for the app alongside any special dependencies which I don’t need to the rest of the process is Next, Next, Finish.

Deployment
When the app is created, distribute the content to any DPs you need it on and then deploy it to your collections as normal.  If you then deploy SCEP to the same collection you’ll soon find that Sophos Antivirus has been removed and SCEP is installed.  You can obviously check any deployments by going to Monitoring \ Overview \ Deployments

Links
https://technet.microsoft.com/en-us/library/gg682067.aspx– About client settings in ConfigMgr
https://www.sophos.com/en-us/support/knowledgebase/109668.aspx– Uninstall Sophos with a Script

I hope this has been useful to you. 

Jonathan.

I have recently been looking at the Microsoft Operations Management Suite and decided to deploy it throughout my datacentre.  First you’ll need to sign up, to start with go for the free version.  This limits you to a certain amount of data per month and only 7 days data retentions. Other plans are available at a cost.

Once you’ve signed up you can start by adding solutions.  I have added in all a few, I went for AD Assessment, Capacity Planning, Malware Assessment and System Update Assessment.  Once you’ve added in your chosen solutions you move on to step two which is to connect your data source(s).  This is the step I’m going to concentrate on in this blog post. It is my intention to deploy the agent available to us through SCCM.  Here’s how I did It.  First, within the Operations Management Suite console, we select step 2 Connect a data source and then in the left pane we can see we can now download our architecture specific agents and we are shown our unique workspace ID and Primary key (blacked out on my screen shot below)

I downloaded the 64 bit agent to its own folder within a sources directory (this sources folder is also a network share) on my ConfigMgr server and then proceeded to manually install it.  Notice this is a .exe file?  Well don’t worry, there is a silent install command I’ll show you. I ensure during installation that I select the option to Connect the agent to Microsoft Azure Operational Insights and specify my WorkspaceID and primary key from the screen shot above.

I can now see that I have a new program installed (by looking in Programs and Features within control panel) called Microsoft Monitoring Agent.  I now need to look within the registry to find its uninstall key – the reason for this will become clear when we add the application into ConfigMgr ready to deploy.

I open up the registry and browse to the following location HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and notice that the uninstall key for Microsoft Monitoring Agent resides under the GUID of {E854571C-3C01-4128-99B8-52512F44E5E9}.

Excellent, right now I fire up ConfigMgr and create a new application so browse to Software Library \ Overview \ Application Management \ Applications right click and new application.

Select to Manually specify the application information then Next,

Give it a name and select Next,

Select Next on the Specify the Configuration manager Application Catalog entry page and on the Configure deployment types and the priority in which they will be applied for this application page, click on the Add… button.

Again, specify you wish to Manually specify the deployment type information and elect Next,

Give it a name and select Next.   Specify your server share in the content location and then use this code for the Installation Program: option

MMASetup-AMD64.exe /C:"setup.exe /qn ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=<your workspace id> OPINSIGHTS_WORKSPACE_KEY=<your workspace key> AcceptEndUserLicenseAgreement=1"

..replacing the two highlighted sections with your own individual WorkspaceIDs and Keys, like this:

Next we need to specify a Detection Method, so from the Specify how this deployment type is detected I click on Add Clause…

I select a Setting Type of Registry and then click Browse…

I drill down to the registry key we found earlier (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{E854571C-3C01-4128-99B8-52512F44E5E9}) and click OK.

I click Next to move onto the Specify the user experience settings for the application page and chose the ones I want, you may want different options here so I’ll let you decide on these.  Finally, I didn't set any Requirements or Dependencies for this application so the rest of the wizard id Next, Next Finish.

Once the application is created don’ forget to distribute the content and then deploy it to the collection of your choice.  It wont be long before you see your servers populating in the console and now all you have to do is decide on whether the free version of OMS is enough for your business needs. That and setting up your logs for the final step.

Hope this has helped you & thanks for reading.

Jonathan.

The Microsoft Assessment and Planning Toolkit is a free tool to download.  You can use it to examine your environment to see whether or not your computers are Windows 10, 8.1 or 7 ready (amongst other things of course).  It can examine a plethora of computers and operating systems using a myriad of connection technologies and it can also be plugged in to Microsoft System Centre Configuration Manager (sort of).

You can start by downloading the tool from: Here...

You will have the option to download the MAPSetup.exe alongside training materials and an example database & documents so you can have a play with it before using it in production if you wish to do so.   This example is done with MAP v9.3.

Since this is a talk about integration with ConfigMgr, I’m assuming you have ConfigMgr and SQL running on the same server.  MAP will use SQLExpress if it doesn’t find a pre-created Instance named MAPS.  in my case I have pre-created the instance as instructed.  When creating your instance remember to set the Collation to “SQL_Latin1_General_CP1_CI_AS”. 
Now that’s done simply follow through MAPS install.

Accept the License Agreement & click Next

Accept the default installation folder and click Next

Personally I always join the customer experience program, then click Next

Finally click Install.

Once installed and launched you’ll know if you got the Instance set up correctly as it will state its connection is to the MAPS instance like highlighted here:

Now that we’ve got that all installed and working fine we can launch the console.  This will enable us to kick off a discovery.  I’m interested in my estates Windows 10 Readiness and so I will click on desktop from the console and then onto Collect Inventory Data.  From here I follow through the steps, first I am interested in Windows Computers…

I select to Use System Center Configuration manager (SCCM)…

Enter my details…

Here’s where it got a little confusing for me.  Here it asks me to enter credentials that will be used for WMI Connectivity.  Surely if ConfigMgr is being used, the connection details to the primary site should be all that’s needed?  ConfigMgr has already hardware audited most of the machines on my estate, so why are WMI credentials needed?  Well, I put them in anyway.

You then need to sort them into order which I have done and then finally the summary confirmation page.

Whilst that’s cooking you’ll get a handy little progress window.

Now, once that’s complete you’ll be able to examine the data.

GOTCHA! and this is where it all falls down for me.  When instructional videos use the words “Integrate with SCCM” or the console states it will ”Use System Center Configuration Manager” I expect MAP to be able to use the data ConfigMgr has collected.  My ConfigMgr client has been installed on my estate, hardware inventory has taken place and that data is stored.  I then expect MAP to access that pre-collected data and SAVE network traffic by reducing the need to go out and use a WMI query to collect data it has access to.  If the data is missing, by all means go out and query for it & report back if it doesn’t work.  This process finishes and then I have a large amount of “Insufficient Data” collected.  More than likely related to the fact a WMI query failed as the device is offline. Rendering the data already collected by SCCM, useless to MAP?

I have started a thread on TechNet about it HERE and I would love for anyone on the MAP team to properly explain this to me (jonnie@deploymentshare.com) perhaps I’ve misunderstood but my only replies have been that the wording on the documentation is kind of misleading and actually SCCM only provides the list of computer names MAP needs to perform the WMI query on, which to me save no network traffic whatsoever. 

Jonnie

References
Link...– MAP homepage
Link...– MAP FAQs
Link…– MAP Prepare the Environment – ADDS and SCCM

Not to brag but, one of the schools we look after at work has been granted Microsoft Showcase School status.  #winning

Part of that status is to do with how the school have adapted and run with OneNote for teaching and learning.  Teachers in the school use the Class Notebook Add-infor OneNote and so here’s my experiences with deploying it.

The first version I came across was 0.3.18.0 and was a downloadable .exe file called ClassNotebookSetup.exe and to get this into ConfigMgr and deployed to clients we wrapped in with a simple batch file after we interrogated the .exe for silent commands we got this:

Excellent.  So I created an application using manual methods (having the correct Office version as a pre-requisite) and using the silent install commands above and boy did I have strange results!  So weird in fact that I lost quite a bit of time to trying to figure out what the heck was going on and took to Twitter to vent my frustration to say “Why isn’t this an MSI!!??”.  In the end I discovered that if I wrapped the application with a simple batch file it worked without error.  So in the folder where the .exe was I create 2 simple batch files with the following lines of code:

   1: ClassNotebookSetup.exe /install /quiet /norestart

   2: md c:\windows\temp\ClassNotebook

Funny because that silent install command on the first line is precisely what I used when I originally created the application but you know, whatever.  I used the ‘make directory’ line so that we could use that folder as a detection clause.  I like doing this because if for some reason you want the application to re-install you can tell the engineers onsite to delete this folder and it will pull back through.

For the uninstall we made a second batch file containing this:

   1: ClassNotebookSetup.exe /uninstall /quiet /norestart

   2: rd C:\Windows\Temp\ClassNotebook

This time uninstalling the software and removing the detection clause folder.

Now, Just recently a new version was released. Currently 0.4.5.0 and can be downloaded HERE but if you click on Other download option on the bottom of the page it will take you to the download for IT Administrators which……… is a MSI!! (Thanks Mike Tholfsen!) .

You can directly download it from HERE (link subject to breaking)

Pretty straight forward task to put an MSI into ConfigMgr.  Once that’s in you can then deploy that using application supersedence to deploy the new version and uninstall the old version.

I have tested this and it all works just fine in my lab (ConfigMgr 1602 + Windows 10 and Windows 7 clients), I’m now happy to push this in production.

PROTIP! Developers don’t rename their products normally so I have gotten into a habit of ensuring the name of the app and the version number is in the name of the app within the console and the software catalogue.  For example if I use the defaults for this class OneNote, the default name is Microsoft Class Notebook Add-in for OneNote and guess what?  So is the new version. Therefore if you add the applications into ConfigMgr with the version numbers on the end and ensure the software catalogue also has the version numbers on the name before you distribute the content anywhere its easy to differentiate between them inside the console and on the clients.  Forget this step and you’ll have weird results.

I hope this is useful for you.

Jonathan.

Following on from my last post I will now write up putting the convenience roll up into a ConfigMgr Application.  Please read my last post for details of prerequisites to installing this update.

Here they are once more

• KB976932 - Service pack 1 for Windows 7 and Server 2008 R2 (KB976932)
• KB3020369– April 2015 Serving stack update (KB3020369)
• KB3125574– Convenience Roll Up (KB3125574)

ConfigMgr Application work

Create a new application and chose to manually specify the application information.

Give it a name and select the tick box highlighted if you want to deploy the app within a task sequence.

I like to give my applications an icon every time so I search the word “update” in an image search and steal one from the internet.

We then select to add a deployment type.

Again chose to manually specify the application settings and click next.  Then give it a name.

Now, within your source structure, you need to place the three files required.  (I’m assuming you already have Windows 7 SP1 installed as you really should by now. This too is a prerequisite!)

1. Update for KB3020369 (Service Stack Update)
2. Update for KB3125574 (Convenience Update Itself)
3. Installer.bat

The installer.bat file has two lines in it, one to install the service stack update and a second to install the convenience update.  Like so:

   1: wusa.exe KB3020369.msu /quiet /norestart

   2: wusa.exe KB3125574.msu /quiet /norestart

!{WARNING} I renamed my downloads to the KB numbers, do not blindly use the above code, check the actual names of your update files.

So, we now specify the content folder within your source structure.

1. Content location – Source folder which contains the three files
2. Installation Program – Installer.bat
3. Uninstall Program – %windir%\System32\wusa.exe /uninstall “KB3125574.msu”

Now we’re going to add a custom script as the detection clause like so..

We’re going to specify a PowerShell script, and the code will be:

   1: Get-Hotfix | Where-Object {$_.HotFixID -match"KB3125574"}

I always change my installation behaviour like so:

I don’t have any Requirements or Dependencies  so I next, next, finish through he rest of the options.

Close the deployment type and next, next finish through he rest of the wizard to create the application.

You now need to Distribute the content to your distribution points and the Deploy the application to a collection.  In my case I tested by deploying to my Pilot machine, you can see here the install was successful.

!{WARNING} I suggest you make this application Available and not Required in production.  The updates takes FOREVER to install and a slip up, such as an end user rebooting in the middle will more than likely cause you problems.  At least if its available, end users can install at their own convenience as long as they are warned it will take a while

I hope this is of use for you.
Jonathan.

Here I will blog about deploying the Configuration Manager Console as an application.  Those of you with a keen eye will have noticed a folder within your Program Files structure “C:\Program Files (x86)\ConfigMgr10\AdminconsoleSetup”.  Within this folder you’ll see a few folders, some encased in curly brackets {} and one not.  You’ll notice, if you explore these folders, that the folder not encased in curly brackets contains an update file, a .MSP, whereas the other folders that are encased in curly brackets contain a single .MSI called AdminConsole.msi.

Console prerequisites
Previous versions have had .NET4 framework (full) as a prerequisite for this application so please ensure you have the latest .NET framework on your machines and this will therefore prevent any issues.  As of the date of writing this, .NET Framework is on version 4.6.2.

Collect Needed Console Files
Within your source stricture create a new folder called ConfigMgr Console and copy in all three files from C:\Program Files\Microsoft Configuration Manager\tools\ConsoleSetup these 3 files are:

AdminConsole.msi
ConsoleSetup.exe
ReportViewer.exe

From within the following location “C:\Program Files (x86)\ConfigMgr10\AdminconsoleSetup” you’ll also need to locate the folder not encased in curly brackets

in which you’ll find the following two files

ConfigMgr1602-AdminUI-KB3155482-i386.msp
UIUpdateManifest.xml

Copy these two files to your ConfigMgr Console folder within your sources structure, now you’re ready to interrogate the MSI for silent install switches and then create an installer.

Exploring the AdminConsole.msi with Orca for Silent Switches
I know from previous reading that you need to throw some switches at the installation for the ConfigMgr console so I’m going to look at it closely with Orca. Everyone knows what ORCA MSI editor is right? Well, for those that don’t it was an application that let you explore the insides of a MSI file, not even sure if its still going or if there’s a replacement but I still use it from time to time.  I’m only going to use it, in this instance, to peek inside the MSI and look for the installation properties for a silent install.  If you don’t have it you can download a copy from here..

Now lets open the AdminConsole.msi within the sources folder into Orca. Once opened I need to examine the Control section and then take note of the text inside the Property column.  If we scroll down we find a property called DEFAULTSITESERVERNAME. and this is relevant on the SpecifySiteServerDialog box.

I know from manually running the setup msi and taking notes that I have to specify the FQDN of my default site server.  So we can therefore determine that this property can be set like so DEFAULTSITESERVERNAME=sccm.domain.local (Edit as you require.)

Next up, I see one for ENABLESQM which is tied to the CEIPDialog box.  Again, I know from attempting the manual install this is related to the customer experience program.  You’re either in or out so this property is either a 0 for in or a 1 for out.

This can therefore be determined as ENABLESQM=1 (For in) or ENABLESQM=0 (For out)

GREAT!

Now lets build that into an application.  I have chosen to share the “%ProgramFiles(x86)%\ConfiMgr10” folder on my ConfigMgr server.  I have done this because can call the new patches as they come out they will be dropped into this “Program Files (x86)” folder and I don’t want to then be copying them to a sources structure each time a new one comes out.  You can handle that as you see fit.  Some may not like the idea of that, I’m not too fussed in my environment.  So from ConfigMgr we chose to add a new program BUT manually specify the options.  Why I hear you cry! when we’re dealing with an MSI, well, we not only have to install the console but we have to apply the update patch we spoke about earlier in order to get it to work so we’re going to use a simple batch file to call two commands.

The first is the following:
msiexec /i AdminConsole.msi /qn TARGETDIR="C:\Program Files (x86)\Microsoft Configuration Manager\Admin Console\" ENABLESQM=0 DEFAULTSITESERVERNAME={FQDN of your ConfigMgr Server}

The second line is the following:
msiexec /p ConfigMgr1602-AdminUI-KB3155482-i386.msp /qn

So lets drop those two commands, on separate lines into a text file and save it as Installer.bat in side the sources folder.  Our entire source folder should now contain 6 files and we’re ready to add a new application.

Application Work

New application.
Manually specify the application information, Next.
Give it a name “Configuration Manager Console (with Update)”, Publisher: Microsoft, Version: 1602.
Tick the box: Allow this application to be installed from the Install Application task sequence action without being deployed, Next.
Download and use a decent icon file for the Application Catalog entry pane, something like this:

Then hit Next.
Add a new Deployment Type.
Manually specify the deployment type information, Next.
Give it a name, Next.
Specify your Content Location. Installation program is Installer.bat.  Uninstall program is msiexec /x{64DC70E3-78F1-4C9F-8E23-B3D1B2F75D3B}.
Detection Clause set to Registry, HKEY_LOCAL_MACHINE and the key is SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{64DC70E3-78F1-4C9F-8E23-B3D1B2F75D3B}.
Installation Behaviour: Install for system.
Logon Requirement: Whether or not a user is logged on.
No requirements or dependencies.
Rest of the Deployment Type wizard is Next, Next, Close.
Rest of the Application Wizard is Next, Next

Actual Deployment
So now we need to distribute the content to our chosen distribution points and then deploy the application to a target collection.

And if for some reason you wanted to remove it, the removal function works too

All tested and working and ready for production.

I hope this helps you and thanks for reading.

Jonathan.

Hello internet!  Sorry I’ve not posted on here in a while.  As some of you know from my twitter feed I’ve recently had a new addition to my family – a baby boy – who is keeping me rather busy and blogging has needed to take a back seat.  I have also re-located to a new town so I’ve been waiting for my internet connection to be hooked up amongst other things, like plumbers and electricians.  Busy busy busy. 

Anyway you don’t come here to read about family life so I’ll get onto my next post.  This one will be about time, and how it can trip you up.

I recently had an issue with time (don’t we all!?) that was affecting site components.  It was only by chance that I discovered that my remote distribution points clock had drifted out of sync with the site servers clock by eleven minutes.  After a little digging around it seems that ten minutes is the threshold and anything over that will cause issues.  I noticed that my site component SMS_DISTRIBUTION_MANAGER had what seemed like millions of error lines in the log and I could see from the distmgr.log that there was clearly an issue.

Site Component Log

distmgr.log

Nightmare!  Right OK so lets examine the time situation and sort this out once and for all.

My site server is a VM that's on a Hyper-V host.  I first fire up a PowerShell window and throw the following command to query the time server source:

   1: w32tm /query /source

Here are the options you may see:
VM IC Time Synchronization Provider = Hyper-V Time Sync Integration Services
DomainController.domain.whatever = Time is synced to the DC, it will show the FQDN of your PDCe
timeserver.location.world = example time.nist.gov will show if this is the time server you set.
Local CMOS Clock = No time sync, time is run off the CMOS clock, this is bad. Really bad.

TIP! you can also use the /computer:xxxxx switch to specify another computer to query, obviously replacing xxxxx with the computer name or FQDN of the computer.

My results are not quite what I expected to see and so I am going to examine the hierarchy of it all and set it up as I want to.  First thing is first, here is a diagram of how I want this to be set up:

In this illustration, my Hyper-V host will sync its time to time.nist.gov and the VM’s on that host will use Hyper-V Integration services to sync their time to the host.  Simple right?

So firstly I’ll examine the host and check that the correct setting is switched on for each VM.  Using Hyper-V manager, select the VM and look at the settings, then under Integration Services ensure that Time Synchronisation is ticked as it is here:

Next we will use the following command in PowerShell to set the Hyper-V host to use our preferred time source:

   1: w32tm /config /syncfromflags:MANUAL /manualpeerlist:time.nist.gov /update

Breaking this command down to better understand it:

/config– Enters configuration mode
/syncfromflags:MANUAL– Sets time to use a manually specified source. (you can use DOMHIER as well if you want to set it up that way)
/manualpeerlist:time.nist.gov–Sets the list of time sources you want to use
/update– Changes cannot be made until either the time service is restarted or the update switch is used.

(again you can use the /computer:xxxxx switch if you need to)

Now when I query the source on the host I get the following:

When I query the three VM’s on that host I get the following results:

So now I’m happy that everything is set up correctly at the remote site.  I know my ConfigMgr site server set up is correct as I’ve used the same method;

I compare the times between the Site Server and the remote Distribution Point and they exactly match up.

I now attempt to redistribute any failed packages and they start & complete without issues.  WINNER!
I now attempt to connect remote WMI and it also works without issue. WINNER!

Next I clear the errors for the SMS_DISTRIBUTION_MANAGER component and reset all the counts.  24 Hours late everything is running fine!

Sometimes strange errors don’t always have a complicated fix or demand lots of your time trawling through logs, sometimes the simplest solution is all that's needed.  I lost a good few hours to attempting to find out what the problem was here and it was only when my wife said to me “what's the time?”,  that I noticed it was out of sync on my servers.  I could have saved myself some of my own time by looking at this first so here is my attempt and saving some of yours.

I hope this was useful to you and thanks for reading.
Jonathan.

Sources
Link– Configuring Windows time for Active Directory
Link– Time Synchronisation in Hyper-V
Link - W32tm

Following on from my post here, where I described adding the Windows 7 Convenience rollup into ConfigMgr as an application.  I will now walk through slipstreaming this into your Windows 7 vanilla image that resides within Configuration Manager using DISM or PowerShell so that its present at every deployment moving forward.

I’m assuming that you have Windows 7 with Service Pack 1 already added into Configuration Manager as an operating system.  If you don't then I highly suggest you look to update your installed operating system because deploying Windows 7 without service pack one in this day and age is frankly bad practice.  With this in mind, there is only one prerequisite we need to consider before we can slip stream the roll up into the image we have (KB3020369).  I’m going to mix up DISM.exe and PowerShell commands in this blog so you can see the difference.

With this in mind lets begin.  First task is to examine your current image file, see what indexes are available and what packages are already installed.  To do this we first use the following commands to identify the indexes stored within the image:

DISM

   1: dism.exe /Get-ImageInfo /ImageFile:C:\yourimagefile.wim

PowerShell

   1: Get-WindowsImage -ImagePath c:\yourimage.wim

The information you get from these commands is basically the same.

For me in this instance I only have one image within the WIM, indexed at 1, so that’s the one I’m concerned about.  I’ll now examine it to see if there are any packages installed.  To do this I must first mount the image to a mount directory.  You can use the following commands.

DISM

   1: dism.exe /Mount-Image /ImageFile:"C:\yourimage.wim" /Index:1 MountDir:"C:\MOUNT"

PowerShell

   1: Mount-WindowsImage -ImagePath "C:\yourimage.wim" -Index 1 -Path "C:\MOUNT"

You see from the PowerShell output above this completed with no ugly red errors and if you look at the specified MOUNT folder, you can see the image is clearly mounted there.

Great! Now lets examine what we’ve got here.  To find out what packages are already installed you can throw the following commands:

DISM

   1: dism.exe /Image:"C:\MOUNT" /Get-Packages /Format:Table

PowerShell

   1: Get-WindowsPackage -Path "C:\MOUNT" | Format-Table

Personally I find the PowerShell output better for this:

Not much to go on as this is vanilla so lets inject the Servicing Stack Update (KB3020369).  Here are the commands to do this:

DISM

   1: dism.exe /Image:"C:\MOUNT" /Add-Package /PackagePath:"C:\yourupdate.msu"

   1: Add-WindowsPackage -Path "C:\MOUNT" -PackagePath "C:\yourupdate.msu"

(You’ve probably noticed my paths are a bit different to yours, don't worry about the paths specified in the command, you’ll need to change them to match your environment I’m just trying to get you some illustrations as we work through this).  Once this is completed we can check packages again to ensure its there.

After adding the prerequisite I then add the Roll Up (KB3155574) – Warning this took ages to install for me.  Be patient.

Now lets save that update to the image.  To do this we can use the following commands:

DISM

   1: dism.exe /Commit-Image /MountDir:"C:\MOUNT"

PowerShell

   1: Save-WindowsImage - Path "C:\MOUNT"

Sweet!

Now we’ll un-mount the directory cleanly. To do this we’ll use the following commands (ensure you close all explorer windows and any other open apps otherwise you may get errors):

DISM

   1: dism.exe /Unmount-Image /MountDir:"C:\MOUNT" /Commit

PowerShell

   1: Dismount-WindowsImage -Path "D:\SOURCES$\Operating Systems\MOUNT" -Save

Now I update the Distribution Points within ConfigMgr ready for testing.


You can then watch the distmgr.log as it recognised that the install.wim has changed and starts to redistribute the new version to your DP.  Obviously give this some time to distribute properly.  Then you can test a deployment and look for the packages within it afterwards.

The yellow above indicates that it is re-distributing.  (I have a dead DP in my estate hence the red slice of the pie! I must solve that at some point – you will be looking for a full green circle when complete)

Once complete, I’ll deploy a test unit and then throw the following command to query the packages installed on that:

   1: dism.exe /online /get-packages /format:table

Here are my results:

Excellent!

Now each Windows 7 image I deploy will have a base of Service pack 1, April 2016 Service Stack Update and the April 2016 Roll up.  That should speed things up for me. 

I hope this has been useful for you & thanks for reading.

Jonathan.

Troubleshooting Site Components
These can give you good information on what is going on in your environment.  You should be checking in on these regularly.  Navigate here:  Monitoring \ Overview \ System Status \ Site Status and Monitoring \ Overview \ System Status \ Component Status and check each component on each page has a nice green check mark next to it, indicating there are no issues.

Here, is an example of one I have an error with:

Seems I have a problem with SMS_AD_SYSTEM_DISCOVERY.  Normally, in my case, one of my sites has had a power cut or an issue with a switch meaning the Data Center cannot contact the server to run a discovery – these sorts of errors usually sort themselves out within 24-48hrs.  To find out what’s going on under the hood I will right click the troublesome component and select to Show Messages and in this case I want to look at Error Messages.  I will chose to look over the ones for the last week.

I can see from this that all errors are the same, they all relate to the same geographical location and that of the two possible causes “The domain controller is inaccessible” is the most likely cause.  I  then prove through testing that the domain controller is contactable so in this particular case I will kick off a system discovery and then check back in shortly to see if the component status has updated to OK.

The theory here is the same for all faults.  You can look in the logs by checking the messages.  You can select to view from a specific time frame and narrow down what the issues may be, undertake some testing (in the case above simple network connectivity testing) and then see if this fixes the issue.  It is also possible to immediately reset the counts of errors and restart the component which should immediately reset the component status to OK so you can monitor to see if the error comes back however I’m not overly fond of that method but I’ll leave that decision up to you.  To do this you would simply right click and chose to reset counts.  Thereafter right click again and select Start > Configuration Manager Service Manager you would then find your component and cycle it or stop & start.

Logs
Obviously each task within ConfigMgr has a log, depending on what you’re doing and what you’re troubleshooting will determine what log to look at.  You should by now be using CMTrace to examine your logs.  This tool is really useful if you want to drill down in the log and not get lost in the ‘white noise’ that spews into it.  For those unaware it finds certain keywords in the log file (.log) such as “error”, “failure” or “warning”) and highlights them accordingly.  You can drill through the log file and narrow down where and issue might be. 

Top tip! – Don’t just read the highlighted lines.  Lines that are NOT highlighted around where the error is can also give you clues as to what's happening

Specific Error (Distribution Point): The package data in WMI is not consistent to PkgLib
I have an ever increasing distribution point collection at my place of work.  We have to place one in each geographical site we support and as that number grows so does the amount of DP’s I have to manage.  I use Distribution Point groups to create groups of DP’s I can distribute content to and therefore once I add on a new DP and it is created successfully, it is added to the group and the corresponding content is distributed down.  Simple huh?  Well I’ve noticed a trend happening just recently that’s weird on one or two distribution points.  The content fails to validate and I’m seeing a yellow triangle on the Distribution Point Configuration node.

My first port of call was to trigger a validation process, you can do this by running smsdpusage.exe.  If you look in your task scheduler list, under configuration manager, you will see that this event is triggered at certain intervals, mine is every day at 23:00.

This task runs:

So we can always run this manually and have a look at the results later on.

Content still showing as error processing?  OK then perhaps we need to turn to PowerShell for this one. I found a cool script (see references Link 3) that I’ll paste here:

   1: $WMIPkgList = Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib | Select -ExpandProperty PackageID | Sort-Object

   2: $ContentLib = (Get-ItemProperty -path HKLM:SOFTWARE\Microsoft\SMS\DP -Name ContentLibraryPath)

   3: $PkgLibPath = ($ContentLib.ContentLibraryPath) + "\PkgLib"

   4: $PkgLibList = (Get-ChildItem $PkgLibPath | Select -ExpandProperty Name | Sort-Object)

   5: $PkgLibList = ($PKgLibList | ForEach-Object {$_.replace(".INI","")})

   6: $PksinWMIButNotContentLib = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq"<=" } 

   7: $PksinContentLibButNotWMI = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq"=>" } 

   8: Write-Host Items in WMI but not the Content Library

   9: Write-Host ========================================

  10: $PksinWMIButNotContentLib

  11: Write-Host Items in Content Library but not WMI

  12: Write-Host ====================================

  13: $PksinContentLibButNotWMI

  14:  

  15:  

  16:#Foreach ($Pkg in $PksinWMIButNotContentLib){ Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib -Filter "PackageID = '$Pkg'" | Remove-WmiObject }

  17: #Foreach ($Pkg in $PksinContentLibButNotWMI){ Remove-Item -Path "$PkgLibPath\$Pkg.INI"}

Notice I have commented out the bottom two lines, so you can run the script and confirm before you take any action.  When you run this is will tell you which package ID are problematic.

Once this has been run and anomalies cleared up you can try a content validation again.  Should this fail you can start to examine which packages are problematic from the results of the script.  Sometimes editing the application to create a new version number will force a correct sync through on the DP, sometimes you’ll need to be brutal and pull the package from every DP and re-create another one.  But eventually, following the steps above this should be cured.  Just a word of advice, be patient!

Specific Error (Software Update Point): WSUS Configuration Manager failed to configure upstream server settings on WSUS Server

Noticed this one appearing every so often on my SUPs too. An error appears on a few components like so..

If you look at the logs for the SMS_WSUS_CONFIGURATION_MANAGER you will see lots of instances of Error Message ID 6600 which states

To solve this you simply follow the solution, crack open IIS and if you drill down to Application Pools you should notice that the WSUSPool has stopped.  Simply start it again and then wait for things to sort themselves out. 

I hope this has been useful for you.

Thanks for reading.
Jonathan.

Link 1– Troubleshooting Content, by Peter Daalmans
Link 2– Content Validation, by Peter van der Woude
Link 3– Content Validation Issues in SCCM 2012, by Jos Lieben

Hello internet!  Here I’m going to delve into the world of automatic computer naming by gateway using ConfigMgr.  Using a reference from Mikeal Nystrom (see links at the bottom of the page)  I’ve got this going with great effect in my environment so I though I’d share.

Firstly, before we go any further you are going to require MDT integration to get this to work.  We will create a MDT Settings package along the way as we create a task sequence and then configure the customsettings.ini to name the devices as we see fit.

So, before we begin we’re going to pre-stage two new folders which is where I want the packages (source) to be stored (I’ll leave the decisions on this up to you) …

..and then create a new MDT integrated task sequence.

Here are the steps I take:

Chose Template – Client Task Sequence
General– Name the task sequence
Details – Set your own details here as you see fit
Capture Settings– This task sequence will never be used to capture an image
Boot Image– Select your boot image
MDT Package– Create a new Microsoft Deployment Toolkit Files package & browse to to the shared UNC of the folder you set up for the files package
MDT Details– Fill in as required
OS Image– Specify your operating systemimage.
Deployment Method– Perform a “Zero Touch Installation” OS Deployment, with no user interaction
Client Package– Specify your client package
USMT Package– Specify your USMT package
Settings Package– Create a new settings package & browse to to the shared UNC of the folder you set up for the settings package
Settings Details – Set your own details here as you see fit
Sysprep Package– No Sysprep package is required

Now you should have your settings and files packages created and those of you who are familiar with MDT can browse the package source folders and recognise what you’re seeing.   Next we’re going to examine how we’re going to set this up moving forward.   Here is a diagram of my current setup

In my situation our main site server is located in a Data Center, it has a WAN link directly to each branch office (of which there are lots!) and in each Branch Office we have a PXE enabled distribution point ready to image OSD Clients.  Each Branch office has its own subnet and in turn, gateway, so if we imagine creating a singular task sequence that can read the gateway address and then apply local settings that suit – That would be awesome!  Lets do that….

First thing we need to do is to crack open customsettings.ini and start programming it as we require.  So if you browse to the sources folder on your site server and locate the folder for the MDT Settings package we created earlier you should see two files.

1. Customsettings.ini
2. Unattend.xml

Open customsettings.ini and lets start editing!!!  Here is how I am going to build up my naming convention.  Four letters to identify the site, followed by a hyphen, followed by a singular letter to denote a laptop, desktop or virtual machine, followed by a hyphen and finally the last 6 digits of the serial number of the machine (some people use the first few digits but in my experience only the last few differ whereas the first few can be the same across multiple machines – this may differ from vendor to vendor please examine the format of SN’s from your vendor carefully).  As an example if my desktop computer was in London, then a generated name example would be LOND-L-123ABC.  Looking at this I can determine where is it and what type of machine it is.  Also, AD is happy because the name is unique as its added on the domain during the process.

Here is a copy of my customsettings.ini

   1: [Settings]

   2: Priority=GenerateSN, Am_I_a_VirtualMachine, Am_I_a_Desktop, Am_I_a_Laptop, DefaultGateway, Default

   3: Properties=SitePrefix, ComputerSerialNumber, ComputerTypeName

   4:  

   5:  

   6:'******  WHOAMI OPTIONS******

   7: [GenerateSN]

   8: ComputerSerialNumber=#Right(Replace(Replace(oEnvironment.Item("SerialNumber")," ",""),"-",""),6)#

   9:  

  10: [Am_I_a_VirtualMachine]

  11: SubSection=VirtualMachine-%IsVM%

  12:  

  13: [Am_I_a_Desktop]

  14: SubSection=Desktop-%IsDesktop%

  15:  

  16: [Am_I_a_Laptop]

  17: SubSection=Laptop-%IsLaptop%

  18:  

  19: [VirtualMachine-True]

  20: ComputerTypeName=V

  21:  

  22: [Desktop-True]

  23: ComputerTypeName=D

  24:  

  25: [Laptop-True]

  26: ComputerTypeName=L

  27:  

  28:  

  29: '****** GATEWAY OPTIONS******

  30: [DefaultGateway]

  31: 192.168.1.1=London

  32: 192.168.2.1=Manchester

  33: 192.168.3.1=Newcastle

  34: 192.168.4.1=Bristol

  35: 192.168.5.1=Barnsley

  36:  

  37:'****** BRANCH OFFICE OPTIONS*******

  38: [London]

  39: SLShare=\\SCCMServer\OSDLOGS$\London\

  40: SitePrefix=LOND

  41: JoinDomain=London.local

  42: OSDDomainName=london

  43: OSDDomainOUName=OU=LONDON COMPUTERS,DC=LONDON,DC=LOCAL

  44:  

  45: [Manchester]

  46: SLShare=\\SCCMServer\OSDLOGS$\Manchester\

  47: SitePrefix=MANC

  48: JoinDomain=Manchester.local

  49: OSDDomainName=manchester

  50: OSDDomainOUName=OU=MANCHESTER COMPUTERS,DC=MANCHESTER,DC=LOCAL

  51:  

  52: [Newcastle]

  53: SLShare=\\SCCMServer\OSDLOGS$\Newcastle\

  54: SitePrefix=NEWC

  55: JoinDomain=Newcastle.local

  56: OSDDomainName=newcastle

  57: OSDDomainOUName=OU=NEWCASTLE COMPUTERS,DC=NEWCASTLE,DC=LOCAL

  58:  

  59: [Bristol]

  60: SLShare=\\SCCMServer\OSDLOGS$\Bristol\

  61: SitePrefix=BRIS

  62: JoinDomain=Bristol.local

  63: OSDDomainName=bristol

  64: OSDDomainOUName=OU=BRISTOL COMPUTERS,DC=BRISTOL,DC=LOCAL

  65:  

  66: [Barnsley]

  67: SLShare=\\SCCMServer\OSDLOGS$\Barnsley\

  68: SitePrefix=BARN

  69: JoinDomain=Barnsley.local

  70: OSDDomainName=barnsley

  71: OSDDomainOUName=OU=BARNSLEY COMPUTERS,DC=BARNSLEY,DC=LOCAL

  72:  

  73:  

  74: '****** DEFAULT OPTIONS******

  75: [Default]

  76: OSInstall=YES

  77: XResolution=1

  78: YResolution=1

  79: BitsPerPel=32

  80:  

  81:'****** TIMEZONE OPTIONS******

  82: TimeZone=085

  83: TimeZoneName=GMT Standard Time

  84: KeyboardLocale=en-GB

  85: UserLocale=en-GB

  86: UILanguage=en-US

  87: AreaCode=01332

  88: CountryCode=044

  89:  

  90: '****** GENERAL OPTIONS******

  91: DomainAdminDomain=%JoinDomain%

  92: DomainAdmin=administrator

  93: OSDNetworkJoinType=0

  94: OSDJoinAccount=%OSDDomainName%\administrator

  95: OSDDiskPart=YES

  96: OSDComputerName=%SitePrefix%-%ComputerTypeName%-%ComputerSerialNumber%

  97: _SMSTSOrgName= %OSDComputername% Coming Soon...

  98: AdminPassword=G4t3man

  99: OSDLocalAdminPassword=P@ssw0rd1

 100: DomainAdminPassword=P@ssw0rd2

 101: OSDJoinPassword=P@ssw0rd2

1. You want the local admin account to be on and set to a singular password for each site, in the examples case this is set to P@ssw0rd1
2.  That you want the domain admin account to be used to add the computer to the domain and the domain admin account has the same password in each branch office, in the examples case this is P@ssw0rd2

Should you not want this (which I’d advise against) you can change this up as you see fit to match your own environments - Here I'm just testing the theory.  I’ll show you how later.  Lets break down the settings and try to make sense of them bit by bit.

   1: [Settings]

   2: Priority=GenerateSN, Am_I_a_VirtualMachine, Am_I_a_Desktop, Am_I_a_Laptop, DefaultGateway, Default

   3: Properties=SitePrefix, ComputerSerialNumber, ComputerTypeName

Here we are stating that the priority order in which the ‘settings’ get processed is denoted by what follows the ‘Priority’ section and that we are setting three properties which are named after the ‘Properties’ section.

   1: '******  WHOAMI OPTIONS******

   2: [GenerateSN]

   3: ComputerSerialNumber=#Right(Replace(Replace(oEnvironment.Item("SerialNumber")," ",""),"-",""),6)#

   4:  

   5: [Am_I_a_VirtualMachine]

   6: SubSection=VirtualMachine-%IsVM%

   7:  

   8: [Am_I_a_Desktop]

   9: SubSection=Desktop-%IsDesktop%

  10:  

  11: [Am_I_a_Laptop]

  12: SubSection=Laptop-%IsLaptop%

  13:  

  14: [VirtualMachine-True]

  15: ComputerTypeName=V

  16:  

  17: [Desktop-True]

  18: ComputerTypeName=D

  19:  

  20: [Laptop-True]

  21: ComputerTypeName=L

Here we are processing the building of the computer name.  The section “GenerateSN” reads the serial number from the computer.  The number denotes how many characters we want and the word “Right” means its taking them from the right inwards so reading left to right that would mean the last 6 digits.  You can change “Right” to “Left” and also the number, should you wish.  It also uses code to replace any dashes and spaces with nothing.  so 65-1234 would become 651234 before it is read into the setting.  (Cool huh!?).  The proceeding sections read the MDT variables and set accordingly.  If you have a desktop, the Am_I_a_Desktop setting becomes Desktop-True and the rest are set to false.  This results in the ComputerTypeName being set to a letter (either V, D or L)

Once we get this far we have processed the settings for GenerateSN, Am_I_a_VirtualMachine, Am_I_a_Desktop, and Am_I_a_Laptop with only DefaultGateway and Default settings left to process.

From this section we generate our “ComputerTypeName” and “ComputerSerialNumber” properties for the name of the computer we are deploying.  The rest of the settings I want to set based on gateway, so here I set up some gateways:

   1: '****** GATEWAY OPTIONS******

   2: [DefaultGateway]

   3: 192.168.1.1=London

   4: 192.168.2.1=Manchester

   5: 192.168.3.1=Newcastle

   6: 192.168.4.1=Bristol

   7: 192.168.5.1=Barnsley

Here we are saying if the default gateway is X process the settings labelled as X.  The first example states if the default gateway is 192.168.1.1 then run the settings for London.  The settings in “London” will be classed as our Gateway settings, so here we can set whatever we like that's going to be specific to the site.  In my case I set the following:

   1: '****** BRANCH OFFICE OPTIONS*******

   2: [London]

   3: SLShare=\\SCCMServer\OSDLOGS$\London\

   4: SitePrefix=LOND

   5: JoinDomain=London.local

   6: OSDDomainName=london

   7: OSDDomainOUName=OU=LONDON COMPUTERS,DC=LONDON,DC=LOCAL

1. Please put all logs for computers deployed at this site into the folder \\SCCMServer\OSDLOGS$\London\.  It will create a folder for each computer so you can trace the logs in case of errors.
2. Please set the SitePrefix property to “LOND”, which is the final property that builds up the computer name
3. Join the computer to london.local
4. Set the OU for the computer account on this domain to be LONDON.LOCAL> LONDON COMPUTERS

Sweet!

It is here you can set alternative security options.  For example if you wanted a different local admin password or domain join account password, they could be set here and built up per site/gateway you configure.  Hopefully as you study the settings we’ve set in this example you should understand how to build up your own custom ones.  If you aren't sure, feel free to ask and I’ll do my best to answer.  Follow me and DM me on Twitter and I’ll help you out, should you need it.

Before I move further, this is a basic example, but consider if you had distribution points in other countries.  At this point you could add any number of the MDT properties to set locale settings, keyboard layouts, time zones – all sorts of things relevant to your environments.  I think that’s pretty cool!  There are lots of MDT properties to explore take a look in the help section of deployment workbench to explore more.

Next we process Default options, which are the settings I want to process on every computer everywhere because they process for each OSD deployment. 

   1:'****** DEFAULT OPTIONS******

   2: [Default]

   3: OSInstall=YES

   4: XResolution=1

   5: YResolution=1

   6: BitsPerPel=32

   7:  

   8: '****** TIMEZONE OPTIONS******

   9: TimeZone=085

  10: TimeZoneName=GMT Standard Time

  11: KeyboardLocale=en-GB

  12: UserLocale=en-GB

  13: UILanguage=en-US

  14: AreaCode=01332

  15: CountryCode=044

  16:  

  17: '****** GENERAL OPTIONS******

  18: DomainAdminDomain=%JoinDomain%

  19: DomainAdmin=administrator

  20: OSDNetworkJoinType=0

  21: OSDJoinAccount=%OSDDomainName%\administrator

  22: OSDDiskPart=YES

  23: OSDComputerName=%SitePrefix%-%ComputerTypeName%-%ComputerSerialNumber%

  24: _SMSTSOrgName= %OSDComputername% Coming Soon...

  25: AdminPassword=G4t3man

  26: OSDLocalAdminPassword=P@ssw0rd1

  27: DomainAdminPassword=P@ssw0rd2

  28: OSDJoinPassword=P@ssw0rd2

OSDInstall = Yes and the strange resolution settings of 1 by 1 pixel is a trick I learned from Johan Arwidmark to trick the computer to use the recommended display settings after deployment.  It tricks the computer because 1 by 1 is an invalid resolution so during OSD the computer will assume the operator is drunk and will ignore your request and set it to the recommended resolution for the graphics card instead meaning you don’t have all your PC’s deploying with 1024x768 and then having to manually change them all.  Cheers Johan!

The Timezone settings are pretty straight forward, I’m setting things up for the UK here.  Adjust to suit.

The rest of the settings should hopefully make sense.  We are building up aspects of our settings bit by bit.  The OSDDomainName property set in our Gateway settings forms part of the account used to add the machine to the domain, in the case of london it would form LONDON\administrator. In the case of the computer name it builds it up using the properties set earlier and adds a hyphen in between each section.  A London Desktop computer example, therefore, would become LOND-D-123456 (where 123456 are the last 6 digits of the serial number).  This makes each computer unique! Just what we wanted.

Fleshing out the task sequence

Now that we can predict what the computer name format is going to look like for each subsequent OSD deployment, we can now flesh out our singular task sequence and deploy apps to certain sites by using WMI queries on the computer name. We know now, for example, that a computer in London will have a naming convention whereby the first four letters of the computer will be LOND.  Now we can add a sections in out task sequence that will only run if the computer name is prefixed with LOND.  Clever right?  This should give you a great foundation for creating the ‘One Task Sequence to rule them all!’ which is where I want my Zero Touch installations to go.

Gotchas

Don’t forget that this isn’t MDT so changes to customsettings.ini are not instant.  When you make a change, you must update the distribution points so that they process the change ready for the next test.

Well, I hope this has been useful for you.  I certainly enjoyed getting this set up and am now in a position where I’m fleshing out that all mighty task sequence to cover multiple sites.

Jonathan.

Reference:
https://deploymentbunny.com/2012/04/21/back-to-basic-customsettings-ini-explained/ - Mikael Nystroms page

In this blog post I am going to describe how to export and import different content within ConfigMgr using PowerShell.  I’ve been exploring how to get content from one site server to another as I don't like repeating work.  I started with connecting my PowerShell ISE environment to ConfigMgr using the ISE add-in written by ConfigMgrDogs  you can find the blog post here.  One ISE is loaded and the add-in is launched, you will see that you have successfully connected when you see a prompt with your site code.  Like so..

(You can of course simply launch the ISE environment from the ConfigMgr console in later versions) Now the fun begins.  The first thing I’m going to do is to search for any commands within the Configuration Manager PowerShell Module that contains the key word “export”.  Using the following command

Get-Command –Module ConfigurationManager | Where Name –Like *export*

Next I’m going to examine Export-CMCollection.  I like the idea of taking my collections with me so I don’t have to rewrite the queries at other sites.  Lets take a look at the examples for the command by throwing Get-Help Export-CMCollection –examples.  (You may need to update your help files at this stage).

OK so pretty straight forward really, it exports collections to a MOF file.    Actually quite handy for me because my non-site specific collections I want to take with me to another site all have the same name prefix of “All” like this…

… so I’ll put a command together using some form of wildcard.  Here is the command I used: 

Export-CMCollection -Name "All*" -ExportFilePath "\\{SERVER-UNC-PATH}\ExportedCollections.mof" –Verbose –ForceWildcardHandling

(obviously change your export path in your situation and the wildcard against the Name parameter)

I can now see I have a MOF File inside the folder I specified! From the above output obviously my wildcard has worked and every collection with a prefix of “All” has been exported to the MOF. Awesome!  You can of course specify individual names for collections if you want to be more specific than I have been above.

I can now transfer that to another site and use Import-CMCollectionto import it using the following command

Import-CMCollection –ImportFilePath “\\{SERVER-UNC-PATH}\ExportedCollections.mof” –Verbose

Verbose output is too long to take a screen shot of as there are three or four lines per collection but that will run successfully.  It will error out if you try to create a collection that already exists, however, so be careful what you export and know the environment you are importing to.  In my case (and the above example) I had an error for this very reason.  This is because I already had a “All Systems”, “All Unknown Computers” and “All Desktop and Server Clients” collections as standard.  (Probably chose the wrong naming convention for my personal ones there but never mind).  I fixed this by manually editing the MOF file but I could have gone back and spent more time being selective about what I was exporting in the first place by changing up my PowerShell command.

So that's Collections, lets try something else.  How about Applications?

Exploring the command results from Get-Command –Module ConfigurationManager | Where Name –Like *export*  I can see there is a Export-CMApplicationcmdlet.  Lets run Get-Help on this and see what we are faced with…

Hmmm… not sure why I would “OmitContent” when exporting an application so lets try to export all my applications to a zip folder taking tips from the above without omitting any content. 

Export-CMApplication -Name * –Path “\\{SERVER-UNC-PATH}\ExportedApplications.zip” –Verbose –ForceWildcardHandling

I can see that after this completed, I have two new objects in the EXPORTEDCONTENT$ folder.  a ZIP file and a folder with content totalling 17GB in my case.

Inside the folder ExportedApplications_files I can see that I have all the distribution point content folders with unique names and subsequently, all the content for the applications.

It is possible for you to export individual applications too, you would simply specify a name rather than a wild card in the above examples.  You could, for example, start to build up a collection of successfully tested and exported applications and take them with you from server to server, saving you the hassle of redoing work over and over – depending on the nature of your role.

OK excellent, so I transfer them to another ConfigMgr server and then Import-CMApplication to import the applications.

Import-CMApplication -FilePath "\\{SERVER}\sources$\Exported\ExportedApps.Zip" –Verbose

Hmm… not a very verbose output haha.  But still! If I now look in my labs blank applications node I see 106 applications I Imported.

Sorry, but that is cool!  It wont remember the folder organisation inside the console you had before (if you had it) but it’ll save you so much time going over the same things. 

You can use the ‘Import application’ right click menu option in the console too

Feel free to try that in your own situation.

What's next?  Lets try packages!

Without going over the same ground (and screenshots) as above, I put together the following command to export my packages:

Export-CMPackage -Name * -ExportFilePath "\\{SERVER}\ExportedContent$\ExportedPackages.zip" –Verbose –ForceWildcardHandling

It runs successfully, in this instance giving quite nice verbose output to the console.  I transfer the files across to another ConfigMgr server and throw this command to import them:

Import-CMPackage -FilePath "\\{SERVER}\sources$\Exported\ExportedAPackages.Zip" –Verbose

Again you can also use the Import Package option from the right click menu in the console to import selectively.

OK I’ll go through one more.  I’m sure that by now I have given you the tools to explore these commands yourself.  Lets examine Export-CMTaskSequence

This time I’m going to use the following command to export all my task sequences:

Export-CMTaskSequence -Name "*" -ExportFilePath "\\{SERVER-UNC-PATH}\ExportedTaskSequences.zip" -Verbose -ForceWildcardHandling

This one has a “gotcha” though.  It will fail to import the task sequence if it cannot resolve the dependencies.  You’ll need to examine the dependencies of the task sequence and ensure you follow the export steps above to grab what you need.  If you run the following command..

Import-CMTaskSequence -ImportFilePath \\{SERVER-UNC-PATH}\ExportedTaskSequences.zip” –Verbose

and it completes successfully, but yet you see no Task Sequences appear, it probably has a dependency error.  For some reason this isn’t outputted to the PowerShell window.  Most likely, the dependency error is due to a missing operating system.  There is no cmdlet for exporting an operating system (why?) and since 99% of task sequences are going to need an operating system its my guess that you’ll probably receive the same errors and frustrations I did.  There is however a saving grace.  A simple one really.  The –IgnoreDependency  switch.  Put this on the end of your command and it wont give a damn about missing dependant operating systems or driver packages (or anything else for that matter) and you’ll be on your own to get them to work after they’re imported.

Import-CMTaskSequence -ImportFilePath \\{SERVER-UNC-PATH}\ExportedTaskSequences.zip” –Verbose –IgnoreDependency

*Victory fist pump*

You can follow the above steps to explore all the other export commands shown in the Get-Command query demonstrated earlier in the blog post and use the examples to export and import different kinds of content in your own environments.

I hope this has been useful to you and thanks for reading.

Jonathan.

Hello all!

Some of you that know me know that I’ve started a new job (week 3) so I’ve been quiet recently as I settle in and try to make a good impression.  All going well so far I’m enjoying it and the people I work with are all nice so that’s great!   Recently I needed to create 15 new packages in SCCM so I decided to make it easier by writing a script for it that did all the hard work for me.

Nothing fancy here if you search about you’ll get lots of help with this as I did but hopefully this will make it easy for you.

First, in order for this to work you’re going to have to connect your PowerShell ISE to your ConfigMgr site.  As mentioned in a previous post you can either connect using the console option…

… or if you’ve got an add on that does it for you you can launch your ISE and run the add on.  As long as the configurationmanager module is loaded and you’re connected to your site you’re ready to go.

Here is the script I wrote

   1: $SourcesLocation = ""

   2: $PackageName = ""#Must be below 40 characters

   3: $PackageDescription = ""

   4: $PackageManufacturer = ""

   5: $PackageVersion = ""

   6: $SilentInstallCommand = ""

   7:  

   8:#Do my bidding PowerShell

   9: If ($PackageName.Length -lt 41) {

  10:     New-CMPackage -Name $PackageName -Description $PackageDescription -Manufacturer $PackageManufacturer -Version $PackageVersion -Path $SourcesLocation

  11:         Write-Progress -Activity "Creating Package" -PercentComplete 25

  12:     Set-CMPackage -Name $PackageName -DistributionPriority Normal

  13:         Write-Progress -Activity "Setting Package" -PercentComplete 60

  14:     New-CMProgram -PackageName $PackageName -StandardProgramName "$PackageName - Program" -CommandLine $SilentInstallCommand -ProgramRunType WhetherOrNotUserIsLoggedOn -RunMode RunWithAdministrativeRights

  15:         Write-Progress -Activity "Creating Program" -PercentComplete 95

  16:     }

  17:     Else {

  18:         Write-Warning "Your package name exceeds 40 characters, shorten and try again!"

  19:     }

Let me break this down for you piece by piece.

Firstly we set the variables.  We need to set six.  I always download my sources files and place them where they need to be first.  Nice neat folders structured in a readable manner so if you were to return to them in 18 months time, you wouldn’t be confused.  Once you have the files ready, be sure of the silent install command you need to run.   You could test this on a pilot box first if you have the time.  Once you have your source files and the silent install command you’re ready to start!

   1: $SourcesLocation = ""

   2: $PackageName = ""#Must be below 40 characters

   3: $PackageDescription = ""

   4: $PackageManufacturer = ""

   5: $PackageVersion = ""

   6: $SilentInstallCommand = ""

$SourcesLocation– set this to the folder share you have your source files.  UNC Path please!
$PackageName, $PackageDescription, $PackageManufacturer and $PackageVersion– Pretty self explanatory.  Remember to keep your package name under 40 characters (will explain later)
$SilentInstallCommand – example “msiexec.exe /i example.msi /qn”

Next we create a blank package using the above variables.  We give it a name.  My personal rule of thumb here is no more than 40 characters.  Why?  Well Because you also have to create a program for the package, and you also have to name to program so what I do is take the package name I chose (as long as its under 40 characters!) and I can append “- Program” on the end (which is ten characters) and the maximum limit you can use for a program name is….. 50 characters long.  So if you can keep your package name short and sweet but to the point the process can be automated neatly.  You don’t have to stick to this of course, you can call your program whatever you like you just have to be careful what you call your program as there is a character limit.  You could opt to add other logic into the script for your own program names but then you wouldn’t be doing it my way which would make it wrong. Right? ha.

So, creating a blank package we use this command:

   1: New-CMPackage -Name $PackageName -Description $PackageDescription -Manufacturer $PackageManufacturer -Version $PackageVersion -Path $SourcesLocation

We can use the command Set-CMPackage to set additional properties, I urge you to explore them and their differences.  In this instance I am only using the –DistributionPriority settings, but there are plenty of others to play around with.

   1: Set-CMPackage -Name $PackageName -DistributionPriority Normal

And finally we need to create a program to go with our package (to actually install the thing!).

   1: New-CMProgram -PackageName $PackageName -StandardProgramName "$PackageName - Program" -CommandLine $SilentInstallCommand -ProgramRunType WhetherOrNotUserIsLoggedOn -RunMode RunWithAdministrativeRights

Here we use New-CMProgramto create the program and set properties.  These properties can be quite important so again, explore the ones available to you from the command either within ISE or the TechNet link I’ve attached to the text.

I have used this code to create a package for 7Zip as an example. Here you can see the properties of my Package, and my Program:

Package

Program

Notice the name of the program is “7Zip v17.00 Beta – Program” and the properties of the program are set to how we want it.

Next steps?  Well you can add on a step to distribute this to a DP or DP Group.  Personally I don't like doing that at this stage I like to get all the packages and programs in first then roll them in one at a time so I can test deployments.

UPDATE: 14.06.17:   I’ve since discovered that this places the package in to the root of the packages folder.  In order to move that package to your folder the code would look like this:

   1: $Move = (Get-CMPackage -Name $PackageName)

   2: Move-CMObject -InputObject $Move -FolderPath LAB:\Package\Microsoft

Where LAB is your site code.

I hope this has been useful for you & thanks for reading.

Jonathan