Find the default gateway on a list of remote servers.
Create a textfile with a list of servers you would like to query, use a new line for each server. If you have an OU of servers you would like to query you could use the following to create a text file with all computer accounts within an OU (requires Active Directory Module for Windows PowerShell).
Get-ADComputer -LDAPFilter "(name=*)" -SearchBase "OU=Servers,DC=domain,DC=local" | Select -expand name | Out-File -Encoding utf8 "\\server\share\Servers.txt"
This would create a textfile with every computer account in the “Servers” OU on domain.local.
I tend to put a “dummy” line at the top of the text file as PSEXEC has issues with the first entry.
Now use PSEXEC to execute the following, don’t forget to run the command prompt as administrator (using an account with the required permissions on the remote servers).
psexec @c:\Serverlist.txt ipconfig /all | findstr "Default Gateway Host" >> c:\Servergateways.txt
…and here’s the final result.
One of the choices for SCEP (System Center Endpoint Protection) definition update sources in SCCM 2012 is from a UNC file share, however in typical SCCM fashion there is a bit of leg work required to use this method. This post will explain the steps involved to make this happen.
1. Create a Folder Structure and Share
Create a folder structure to share the SCEP definition update files, the top level folder name does not matter, in this example I’m using SCEPUpdates. Within this folder create two folders, one named x86 for x86 machines and one named x64 for x64 machines. Share the SCEPUpdates folder. Ensure the client computers and the domain users connecting to the share have read permissions to the share. During an automatic update, the client computer account is used to authenticate to the share. When a user manually updates their definitions by clicking Update, that user account is used to authenticate to the share. You will want to use DFS or similar if you have multiple locations to distribute the files.
2. Powershell Script to Automate Definition File Downloads
There are 6 files in total to download, 3 for x64 machines and 3 for x86 machines.
- Mpam-fe.exe – Full Definitions
- Mpam-d.exe – Delta Definitions
- Nis_full.exe – Network-based exploit definitions
For more information and direct links to the definition files see here (or refer to the Powershell script below).
I’ve put together a Powershell script to download the 6 definition update files to a UNC path.
$x64S1 = "http://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x64" $x64D1 = "\\server\SCEPUpdates\x64\mpam-fe.exe" $x64S2 = "http://go.microsoft.com/fwlink/?LinkId=211054" $x64D2 = "\\server\SCEPUpdates\x64\mpam-d.exe" $x64S3 = "http://go.microsoft.com/fwlink/?LinkId=197094" $x64D3 = "\\server\SCEPUpdates\x64\nis_full.exe" $x86S1 = "http://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86" $x86D1 = "\\server\SCEPUpdates\x86\mpam-fe.exe" $x86S2 = "http://go.microsoft.com/fwlink/?LinkId=211053" $x86D2 = "\\server\SCEPUpdates\x86\mpam-d.exe" $x86S3 = "http://go.microsoft.com/fwlink/?LinkId=197095" $x86D3 = "\\server\SCEPUpdates\x86\nis_full.exe" $wc = New-Object System.Net.WebClient $wc.DownloadFile($x86S1, $x86D1) $wc.DownloadFile($x86S2, $x86D2) $wc.DownloadFile($x86S3, $x86D3) $wc.DownloadFile($x64S1, $x64D1) $wc.DownloadFile($x64S2, $x64D2) $wc.DownloadFile($x64S3, $x64D3)
This is great for one off downloads, but we want to automate the task. The next step is to create a schedule task to the run the script every x hours. The action should point towards the Powershell script above, you can simply use powershell -file “script.ps1″ as the action.
This schedule kicks the first download off every day at 12:05am and updates the definition files every 4 hours.
Confirm the scheduled task is running every 4 hours and updating the files correctly before moving onto the next step.
3. Configure Definition Update Sources
Open the System Center 2012 Configuration Manager console and browse to Assets and Compliance -> Endpoint Protection -> Antimalware Policies and select the policy you would like to configure.
From the left hand menu choose Definition Updates and choose “Set Source”. Tick “Updates from UNC File Shares” and move to the top of the list, un-tick other sources if necessary. Click OK.
Choose Set paths, add the UNC path and OK.
To confirm the clients are pointing to the right location and using the UNC share configured above, wait (or manually) update the client’s policy and browse to the following registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Signature Updates (or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Microsoft Antimalware\Signature Updates) and review DefinitionUpdateFileSharesSources.
When PXE booting and deploying a task sequence you receive the error “Failed to resolve selected task sequence dependencies” and no dependency or package IDs are displayed.
1. Press F8 when in the WinPE environment to open the command prompt – Click here if you have not enabled the command support console.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log which is responsible for deployment and task sequence log events type notepad X:\Windows\Temp\SMSTS\SMSTS.log (the task sequence dependency check happens prior to any formatting of the HDD, hence the location of the log file). At this stage you can also plug in a USB drive and copy/save the log onto it.
3. Open the log file with the Configuration Manager Trace Log Tool aka CMTrace.exe, this will make it a lot easier to view and find the offending errors. If you do not have CMTrace, you can grab it from the SCCM media under SMSSETUP\TOOLS. It’s a single executable so can be copied and moved around as necessary.
4. Near the bottom of the log file you should observe similar errors:
Failed to find CCM_ApplicationCIAssignment object for AdvertID=”12003A”, ModelName=”ScopeId_59CA012F-1C99-45CD-9184/Application_64ff713e-87d1-40dc-8d24-16961ccff5bb”
Failed to resolve selected task sequence dependencies. Code(0×80040104)
ThreadToResolveAndExecuteTaskSequence failed. Code(0×80040104)
The part we’re interested in is the second part of the ScopeId, in this case: Application_64ff713e-87d1-40dc-8d24-16961ccff5bb. To find out which application this refers to open the System Center 2012 configuration manager console. Browse to Software Library, Operating Systems, Task Sequences and select the required task sequence. At the bottom choose “References”, this will show you all applications assigned to the task sequence and their Object IDs. Match this up with the error found from the SMSTS.log.
In my case the offending application was Sage Accounts 2014. Things to check:
- Make sure the application has been distribution to the required distribution point(s).
- Try removing it from the distribution point(s) and re-distributing.
- If the above fails, simply remove the application from the task sequence and re-add it (this was my issue!).
Troubleshooting SCCM Operating System Deployments can be tough, to ease the pain you can enable the command support console for use within the Windows Preinstallation Environment. Doing so will give you access to the command prompt, the SMSTS.log and the ability to launch various other applications to aid in troubleshooting. I will show you how to enable the console, then give a couple of examples.
Enabling Command Support Console (F8)
1. Open the System Center Configuration Manager Console.
2. Browse to Software Library -> Operating Systems -> Boot Images and select the boot image you would like to add command support to.
3. Right Click the boot image and select properties.
4. Head to the Customization Tab and tick “Enable command support (testing only)”.
You will then be prompted with “You have made changes that require you to update distribution points with a new version of this package – Do you want ConfigMgr to update the distribution points now?”.
5. Click Yes.
6. Work will then be done on the Boot.wim, which will in turn be re-distributed. Current size of the boot.wim without any additional drivers added is around 160MB so distribution shouldn’t take too long- even with slow links. Next, next until the process is completed.
Once the updated boot.wim has been distributed, PXE boot into WinPE. You will now be able to access the command prompt by pressing F8.
Open the SMSTS.log
The SMSTS.log is the main log file for diagnosing OSD and Task Sequences client side. The location of this file changes through various steps of the task sequence.
WinPE Before HDD is formatted: x:\windows\temp\smstslog\smsts.log
WinPE After HDD is formatted: x:\smstslog\smsts.log
Windows, SCCM agent not installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Windows, SCCM agent installed: c:\windows\system32\ccm\logs\Smstslog\smsts.log
Windows x64, SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
1. Press F8 when in the WinPE environment to open the command prompt.
2. You can view the SMSTS.log file on the live system, or move it to another machine to interrogate. To open the SMSTS.log type notepad X:\Windows\Temp\SMSTS\SMSTS.log (in this case this is the SMSTS.log prior to formatting the HDD). At this stage you can also plug in a USB drive and copy/save the log onto it.
Taking a screenshot
It can be useful to have the ability to take screenshots from within WinPE. To do so, you can map a drive (or use a USB stick) and use a utility called nircmd.
Here we map a drive with net use j: \\server\share password /user:user then run nircmd from the mapped drive.
Savescreenshotwin will only capture the command prompt window, whereas savescreenshotfull will capture the entire environment (probably more useful).
Hopefully this post will have improved your ability to troubleshoot OSD and task sequence issues, and open up the possibility of running other applications (e.g. process monitor) from within WinPE.
In the last few posts we’ve looked at moving away from Internet Explorer Maintainence within Group Policy as it has been deprecated from Internet Explorer 10 and above. There are two clean methods to remove these settings from Group Policy, the first is simply unlinking the GPO that has been configured with these settings. However if you have configured IEM within your Default Domain Policy or another GPO that you’d like to continue using, you are able to remove any settings configured with Internet Explorer Maintenance by right clicking and choosing Reset Browser Settings.
There is often a requirement to maintain and add URLs to the security zones of Internet Explorer. As we discussed in the last couple of posts, Internet Explorer Maintenance (IEM) has been deprecated with Internet Explorer 10. This post will look at two ways to leverage group policy to manage the security zones. The first method will remove the option for the end user to edit or change the security zones, the second will allow the user to add or remove sites.
Site to Zone Assignment List
Create a new Group Policy Object and browse to
User Settings -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page.
Double click on the Site to Zone Assignment List, select enable and choose show to configure the options.
Note the numbering of the Security Zones. 1 for Intranet Zone, 2 for Trusted Sites, 3 for Internet Zone and 4 for Restricted Sites Zone.
In this example I have added http://intranet.corp.local to the Trusted sites (2).
Using this method will grey out the Trusted sites GUI, meaning the end user cannot remove or add any sites to any of the zones.
If you would like to be a little more flexible and allow the end users to edit the zones you will need to use an alternative method. Group Policy Preferences Registry Items. Consider the implications of allowing this, as users can add their own sites and potentially reduce the security settings for a given site.
Group Policy Preferences Registry Items
This method will allow you to deploy Security Zone sites, whilst allowing the end user to modify the zones by adding or removing sites. If a user removes one of the sites deployed via this method, it will be re-added on the next Group Policy refresh.
I’ve covered deploying registry settings via Group Policy Preferences in a previous post, so you may want to have a quick scan if you’re not familiar.
Create a new Group Policy Object and browse to
User Configuration -> Preferences -> Windows Settings and Registry. Right click and choose new Registry Item. This is where you’re configure the sites, you will need 1 registry item per site.
- Key path format is as follows: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\website.com\www\
- Value name will typically be http or https
- Value type is REG_DWORD
- Value Data uses the same as Site to Zone Assignment. 1 for Intranet Zone, 2 for Trusted Sites, 3 for Internet Zone and 4 for Restricted Sites Zone.
This is what you will see on the client machine.
If you want to set the “Require server verification (https:) for all sites in this zone” with this method, you can do so by setting the following.
- Key path format is as follows: Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2
- Value name is Flags
- Value type is REG_DWORD
- Value data is 67 to untick this option, and 71 to tick- make sure the base is set to Decimal
- User Site to Zone Assignment to prevent users from editing the Security Zone Sites
- User Group Policy Preferences to allow users to edit the Security Zone Sites