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.

The post Group Policy – Removing Internet Explorer Maintenance Settings appeared first on The Sysadmins.

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.

The post SCCM 2012 SP1 – Enable Command Support Console in WinPE appeared first on The Sysadmins.

Problem

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.

Solution

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!).

The post SCCM 2012 – Failed to Resolve Selected Task Sequence Dependencies appeared first on The Sysadmins.

It’s been around a while, but the IT Crowd is well worth watching if you haven’t seen it before- all 4 seasons are up on Netflix. Here’s one of my favourite clips.

The post The IT Crowd appeared first on The Sysadmins.

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.

The post SCCM 2012 – SCEP UNC Definition Updates Automation with Powershell appeared first on The Sysadmins.

Problem

Find the default gateway on a list of remote servers.

Solution

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.

The post Get Default Gateway from List of Remote Servers appeared first on The Sysadmins.

GPResult is a command-line utility for determining the resultant set of policy for a given user and/or computer. In other words, it shows you what Group Policy Objects have been applied and their settings. This is typically one of the first tools I go to when troubleshooting Group Policy from a client once basic connectivity has been confirmed (e.g. Network/DNS). The tool itself is very simple to use and I will run through some common examples below.

List GPOs Applied with Summary Data

Gpresult /r

/r Displays RSOP summary data

This is pretty useful when you simply want to see what GPOs have applied and in what order. It will also display summary data, such as last time group policy was applied, which Domain Controller it was applied from, the site, security groups and if the slow link threshold has been activated. If you are unsure if a GPO has been applied, this is a quick way of checking.

Here we see that 4 GPOs have applied to the Computer settings portion.

If you don’t want to view both Computer and Users settings in the output you can request one or the other with the /scope flag.

gpresult /r /scope:user

gpresult /r /scope:computer

The output reads fairly well from within the command prompt, but if you need to export the output you could use either of the following.

Gpresult /r > gpresult.txt Export output to a text file
Gpresult /r |clip Export output to Windows clipboard

I can’t see the Computer Settings?

If UAC is enabled, running GPResult without elevating the command prompt will only show you the user settings. If you want to see both user and computer settings, elevate the command prompt by either tapping the winkey+cmd then ctrl+shift+enter or right click on the command prompt and select run as administrator. If you elevate with an admin account different to the currently logged in user (common if the user does not have administrator rights), then you will receive an error message stating INFO: The user “domain\user” does not have RSOP data. This is because GPResult is using the elevated user’s context. To work around this, specify the standard user that you are troubleshooting.

gpresult /r /user:sa\edward.thomas

Generate HTML Report

Gpresult /h report.html /f

Gpresult /h report.html /user:sa\edward.thomas /f

/h Saves the report in HTML format
/f Forces GPresult to overwrite the file name specified with /h
/user Specifies the user name for which the RSOP data is to be displayed

To get a more graphical view of what’s going on, you can generate a HTML report. This gives a detailed break down of each setting and the GPO from which it came. This view is particularly nice as you can show all and use ctrl+f to find a particular policy or setting.

Run GPResult on Remote Computer

Gpresult /s server1 /r

/s Specifies the remote system to connect to

This allows you to run GPResult on a remote system, all of the above applies.

The following GPOs were not applied because they were filtered out

You may see this for a few reasons. The first that the policy is empty in which case you’ll see Filtering: Not Applied (Empty), this is fairly self explanatory. The second is Filtering: Denied (Security), which typically boils down to the “Apply Group Policy” permission on the GPO. You may also see Filtering: Denied (Unknown Reason) which is similar to (Security) in that the “Read” permissions has been denied.

To review the last two examples, launch the GPMC (Group Policy Management Console). Find the offending GPO, and select Delegation- from there you may see an additional group or a single user or machine that has been added.

Click on advanced and review the permissions against the object. In this case you can see that the Seven computer object has been denied Apply Group Policy resulting in the Filtering: Denied (Security) message.

If in doubt, select Advanced -> Effective Access and enter the required computer or user object. If you scroll down to around halfway you’ll see the Apply Group Policy permission with either a green tick of a red cross against it. If deny read has been granted every permission will have a red cross next to it.

I hope this gives you the basics behind GPResult and some good real world example to aid in your Group Policy troubleshooting.

The post Group Policy – GPResult Examples appeared first on The Sysadmins.

Issue

In a recent update to the iOS Remote Desktop client (8.1.0 and above) you receive the following error when connecting using a Remote Desktop Gateway: Can’t connect to the Remote Desktop Gateway. Contact your network administrator for assistance. (Error code: 0x03000008)

Confirmed on the Remote Desktop Services blog here.

Fix

1. Review the TerminalServices-Gateway operational event log on the Remote Desktop Gateway server and look for EventID 301 which states: The user “DOMAIN\user”, on client computer “1.2.3.4”, did not meet resource authorization policy requirements and was therefore not authorized to resource “172.17.50.10”. The following error occurred: “23002”.

The resource IP should be one of your RDS servers, note healthy connections to the Gateway should (typically) specify the FQDN of the RDS server it is trying to connect to: The user “Domain\user”, on client computer “1.2.3.4”, met resource authorization policy requirements and was therefore authorized to connect to resource “RDS-NY-2.domain.co.uk“.

2. Open the RD Gateway Manager MMC on your Gateway server, go to Policies, Resource Authorization Policies (RAP) and review the policy you have configured for your company- note the locally stored computer group used.

3. Choose Manage locally stored computer groups from the right hand side, select the group used in the policy and select properties.

4. Add the IP for each of the RDS servers in the farm (keep hostname and FQDN if present).

Once this is complete it should resolve the issue. Review the TerminalServices-Gateway operational event log and you should now see: The user “DOMAIN\user”, on client computer “1.2.3.4”, met resource authorization policy requirements and was therefore authorized to connect to resource “172.17.50.10”.

This issue/bug/feature is still present in the Remote Desktop iOS application version 8.1.5 from 29th October.

The post Remote Desktop iOS 8.1.0 – Error 0x03000008 appeared first on The Sysadmins.

This mini-series will guide you through installing and configuring Ubiquiti’s Unifi Wireless solution using 802.1x, Windows NPS (radius) and Group Policy. This post will cover the installation of the Unifi Controller. The following posts will cover configuring the controller, NPS and deploying Wireless settings via Group Policy to your endpoints. I will add any relevant or helpful links at the bottom of each post.

The setup for this mini-series is as follows:

• Server 2012 R2 member server hosting the Unifi Controller and Network Policy Server (NPS)
• Windows 7/8.1/10 Clients
• Unifi Controller 4.6.6

Unifi Controller Installation

From the Server 2012 R2 member server:

1. Install the latest Java (8u51). Unifi recommend that if you are using an x64 operating system to install both x86 and x64 version of Java for the Unifi controller service to correctly start
2. X64 Offline install (8U51): http://javadl.sun.com/webapps/download/AutoDL?BundleId=107944
3. X86 Offline install (8u51): http://javadl.sun.com/webapps/download/AutoDL?BundleId=107943
4. Install the latest Unifi Controller (4.6.6): http://dl.ubnt.com/unifi/4.6.6/UniFi-installer.exe.
5. Accept the defaults, but untick “Start Unifi Controller after installation”

The controller installs into “C:\Users\%username%\Ubiquiti Unifi” by default and there is no way to change this when installing, however moving it isn’t too difficult. Simply Copy the entire folder and move it to the required location e.g. C:\Ubiquiti Unifi.

Now that the installation has been moved, you will want to configure the Unifi Controller to run as a service. If this is not done, the Unifi Controller will need manually starting by a logged in user. When the user logs out, the controller software will close.

From an elevated command prompt run

java –jar "C:\Ubiquiti Unifi\lib\ace.jar” installsvc

Start the service with

net start “Unifi Controller"

To access the controller browse to https://127.0.0.1:8843 to start the UniFi setup wizard.

• Choose you country and timezone
• No devices discovered, next
• Skip Wireless configuration for now
• Set your username and password, next and finish

The controller has now been installed and initially configured.

You can also uninstall the service for troubleshooting if need using

java –jar “C:\Ubiquiti Unifi\lib\ace.jar” uninstallsvc

Access Point Adoption

Last thing to do as part of the initial setup is to configure adoption for the access points. When you plug an access point in, you want them to automatically point at your Unifi Controller to receive their configuration and updates. This can be achieved a few ways, but layer 3 adoption via DNS is reliable and easy to configure.

Create a “unifi” A record that points to the server that you have installed the controller on. The Unifi AP will need to contact the controller via it’s FQDN.

Links

Buy Unifi @ linitx.com
Buy Unifi @ 4gon.co.uk
Unifi Community Layer 3 Adoption Methods
Unifi Community Run Controller as Service
Unifi Community Java 8 Support Notes

The post Unifi Wireless – 1. Installing the Controller appeared first on The Sysadmins.

This post will explain how to automate the deployment of XenClient Enterprise Engine 5.5.5 using SCCM 2012 R2. There is very little information on how to achieve this, so hopefully this will help those looking for a solution. Thanks goes to a post made by Greg Roll early last year on the Citrix discussion forums which pointed me in the right direction. There were a few bits missing and lacking detail, which I will cover.

Preparing the files

Download the XenClient Windows Installer (xce-engine-setup-5.0.exe under additional software) and run it on a disposable Virtual Machine. When prompted, select the latest Engine ISO and continue

Select Resize Windows

Leave these options unticked

Next to start the installation and select no when prompted to reboot

There will be installation files dropped on the C drive – move these to your SCCM file share or the location you use for SCCM applications/packages

You will then need to move a few files around.

1. Create a new folder called Engine and move the nxtop folder into it. Then move the nxtldr and nxtldr.mbr files from winboot to the root of the Engine folder. Rename them to grldr and grldr.mbr
2. Download Grubinst and move grubinst.exe into the Engine folder
3. Download psshutdown.exe and move psshutdown.exe into the Engine folder

You should end up with this:

Client.ini

You can achieve a fair amount of automation using the Client.ini file found in the boot folder. The following focuses on performing an auto installation into the XenClient Engine, ready for registration. The two variables you will want to pay specific attention to are assettag and name. In the example below I have used @baseboard-asset-tag@ which will pull the asset tag from the BIOS (tested with Dell laptops). Be aware that you cannot change the name of the owned computer once deployed and would need to redeploy the Engine to rename.

Example Client.ini
# Minimum parameters to perform an auto install are:
# name
# assettag
# encrypt
# keyboard
[GLOBAL]
action=install
assettag=@baseboard-asset-tag@
continue_on_no_space_for_recovery_partition=no
create_engine_recovery_partition=no =
encrypt=yes
kb=gb
Action = wipeinstall
lang=en
name=@baseboard-asset-tag@
require_mac_match=no
shrink_partitions_if_no_disk_space_is_found=yes

Other available DMI keywords:

@bios-vendor@ @bios-version@ @bios-release-date@ @system-manufacturer@ @system-product-name@ @system-version@ @system-serial-number@ @baseboard-manufacturer@ @baseboard-product-name@ @baseboard-version@ @baseboard-serial-number@ @baseboard-asset-tag@ @chassis-manufacturer@ @chassis-version@ @chassis-serial-number@ @chassis-asset-tag@ @processor-manufacturer@ @processor-version@

More information on editing the Client.ini file can be found here.

Create the Package in SCCM

Next step is to package the folder structure created above, ready to use within the Task Sequence.

Create a new package in SCCM

Next through the remaining screens and distribute the package as necessary.

SCCM Task Sequence

1. Format the disk

cmd /c "(echo select disk 0& echo clean) | diskpart"

2. Create a small 4GB FAT32 partition to copy the XenClient Engine files to

3. Deploy the package, this essentially just copies all of the files from the package to the root of 4GB FAT32 partition

xcopy.exe ".\*.*" "c:\" /D /E /C /I /Q /H /R /Y /S

4. Run GrubInst.exe against HD0

5. Restart

The standard restart option was throwing up an error, so psshutdown can be used as a workaround.

The machine should now boot into the XenClient Enterprise Engine installation and perform an auto installation. Once finished you will then be able to register the Engine with a user.

Good luck!

The post Deploying XenClient Enterprise Engine with SCCM appeared first on The Sysadmins.

What is LAPS?

A lot of organisations will use the same local administrator password across all machines, which is a bad idea for a number of reasons. At a basic level, if this password is learnt, it allows anyone to install software as an administrator – at a higher level it facilitates things such as pass the hash, mimikatz and general reconnaissance against your machines (usually with the goal of elevating to Domain Admin).

If you currently deploy your Local Administrator Account via Group Policy Preferences, this makes things even easier for an attacker to obtain the shared local administrator password. The CPASSWORD value is easily searchable against SYSVOL and Microsoft provide the 32-byte AES key which can be used to decrypt the CPASSWORD. Alan has a great post here why you should stop using Group Policy Preferences for deploying Local Administrators.

So what can we do?

LAPS – Local Administrator Password Solution! This is Microsoft’s solution to managing Local Administrator account passwords across an organisation. LAPS solution features include:

• Sets a unique randomly generated password PER machine
• Automatically change the Local Administrator Password every x days
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Password is protected during the transport via Kerberos encryption

This post will cover preparing Active Directory and deploying LAPS to the machines you wish to manage. Part 2 will cover enabling LAPS via Group Policy, and general usage.

Management Machine

First off, we’re going to install the management portion of LAPS. Download LAPS here and next, next through the installation. On the custom setting page choose all of the management tools. The AdmPwd GPO Extension is required if the machine you’re installing the management portion on will also be managed by LAPS.

Follow ‘Preparing Active Directory’ on the management machine.

Preparing Active Directory

1. Extending the Active Directory Schema

The Active Directory Schema needs to be extended to add two attributes to the computer class. These are ms-MCS-AdmPwd which stores the password in clear text, and ms-Mcs-AdmPwdExpirationTime which stores the password expiration time. You will need to be a member of the Schema Admins security group.

Import-module AdmPwd

Update-AdmPwdADSchema

2. Adding Machine Rights

You need to delegate to right to allow the computer object to write to the ms-MCS-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes.

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=SA Computers,DC=thesysadmins,DC=co,DC=uk”

This sets the following permissions against all computer objects within the OU specified, including all child objects.

This is what the Set-AdmPwdComputerSelfPermission cmdlet does behind the scenes on the computer objects ACL:

3. Check ExtendedRights permissions on OU

To get information on the groups and users able to read the password (ms-MCS-AdmPwd) for a specific Organizational Unit (OU), run the following.

Find-AdmPwdExtendedRights -identity:"OU=SA Computers,DC=thesysadmins,DC=co,DC=uk" | Format-Table ExtendedRightHolders

4. Remove ExtendedRights permission on OU

If you need to remove the permission to view the password (ms-MCS-AdmPwd) for a group or user, carry out the following.

1. Open ADSIEdit
2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties
3. Click the Security tab
4. Click Advanced
5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit
6. Uncheck All extended rights

5. Delegate a Security group the rights to view and reset LAPS

Here I’m delegating the Security Group ‘LAPS’ the right to view the LAPS Password and to have the ability to reset the password (more on that in part 2). I’ve re-run the ExtendedRights cmdlet, and you can now see that the LAPS group has been added.

Set-AdmPwdReadPasswordPermission -OrgUnit "OU=SA Computers,DC=thesysadmins,DC=co,DC=uk " -AllowedPrincipals "LAPS" 

Set-AdmPwdResetPasswordPermission -OrgUnit " OU=SA Computers,DC=thesysadmins,DC=co,DC=uk " -AllowedPrincipals "LAPS"

This is what the Set-AdmPwdReadPasswordPermission and Set-AdmPwdResetPasswordPermission cmdlets are doing behind the scenes on the computer objects ACL:

Active Directory is now prepared!

Deploying LAPS

Deploying LAPS is very straight forward, and can be deployed via Group Policy, SCCM, Login Script, manual install etc…

Examples:

Deploying LAPS to x64 machines (by default no management tools are installed, only the CSE required to manage the computer)

msiexec /q /i \\server\share\LAPS.x64.msi

Deploying LAPS to x86 machines

msiexec /q /i \\server\share\LAPS.x86.msi

Optional Deploying LAPS to x64 machines and create a custom admin account “LocalAdmin” during setup

msiexec /q /i \\server\share\LAPS.x86.msi CUSTOMADMINNAME=LocalAdmin

Group Policy

If you want to deploy a new custom Local Administrator Accounts via Group Policy, due to the limitation of software installation you will need to use Orca or InstEd to generate a MST to pass the CUSTOMADMINNAME value. Edit the Property Table, and replace __null__ with the name of the Local Administrator you’d like to create.

SCCM

To confirm the installation has succeeded, confirm that C:\Program Files\LAPS\CSE\AdmPwd.dll is present.

The bulk of the deployment has now been completed. In part 2 we will cover Group Policy which will essentially turn LAPS on, how to view passwords and some general discussion on the solution.

Microsoft Local Administrator Password Solution (LAPS) – Part 2 Coming soon

The post Deploying Microsoft LAPS – Part 1 appeared first on The Sysadmins.

We recently covered preparing Active Directory and deploying the LAPS CSE/Client to the machines you wish to manage in part 1 of deploying Microsoft LAPS. Part 2 covers “Turning on” LAPS via Group Policy, the LAPS process and how it works once deployed.

Group Policy

On your LAPS management machine head to C:\Windows\PolicyDefinitions, there you will find AdmPwd.admx and AdmPwd.adml (under en-US). Copy these files into your Group Policy Central Store, if you do not have a Central Store (and do not which to create one) you can launch Group Policy Management Console directly from your management machine, or copy the ADMX/ADML to a Domain Controller where you will be editing the policy.

Create a new GPO and navigate to Computer configuration -> Policies -> Administrative Templates -> LAPS

Password Settings
This is where you’ll choose your password policy. The default is complex passwords, 14 chars and a password age of 30 days (machines will automatically change their password when this is met).

Name of administrator account to manage
In part 1 we deployed a custom local administrator account of LocalAdmin, this is the account I wish to manage. Leave this to not configured to manage the default Administrator account (-500).

Enable local admin password management
Enable this setting to turn LAPS on.

Do not allow password expiration time longer than required by policy
When you enable this setting, planned password expiration longer than password age dictated by “Password Settings” policy is NOT allowed. When such expiration is detected, password is changed immediately and password expiration is set according to policy.

Link the GPO to the OU with the computer objects you wish to manage with LAPS (and that you have deployed the LAPS client to).

The LAPS process

1. Machine with LAPS CSE queries Group Policy and receives the LAPS policy settings defined above
2. Machine queries ms-Mcs-AdmPwdExpirationTime, if not set, or expired it will generate a new password and set this locally and securely write this value to the mc-Mcs-AdmPwd attribute in Active Directory
3. Password is now set locally, stored in Active Directory and is ready for use
4. The LAPS CSE will query this value on each Group Policy update, when the ms-Mcs-AdmPwdExpirationTime is met, or the attribute is not set it will re-generate a new password
5. If machine cannot contact Active Directory, no changes are made

Using LAPS

If you’ve followed all of the steps so far, the solution will now be fully deployed. There are various ways you can view the password set by LAPS. The most obvious choice, and probably what most people will default to using is the LAPS UI which is installed as part of the LAPS management tools.

1. LAPS UI – Simply run the UI, type the computer name and click search.

Note the Reset button. This allows you to manually manage when the password is re-generated for a given machine. If you want to expire the password immediately, click reset with the current date and time set. The next time the computer performs a gpupdate, it will check the ms-Mcs-AdmPwdExpirationTime attribute which will force it to re-generate a password (as it will have expired). You can also set it to a specific date and time if required.

2. Powershell – Get-AdmPwdPassword cmdlet

Import-Module AdmPwd.PS

Get-AdmPwdPassword Client01

3. Active Directory Users and Computer (DSA.MSC) – Make sure you have advanced features ticked from the view tab.

Note the expiry time is in NT system time, to convert to a readable format, use w32tm /ntte %ms-Mcs-AdmPwdExpirationTime%.

If you’re looking at a Local Administrator Password solution, currently using GPPs to deploy Local Administrator accounts or simply want to increase the security of your machines LAPS is absolutely something you should look to implement. I hope you’ve found these posts helpful, and good luck!

Microsoft Local Administrator Password Solution (LAPS) – Part 1

The post Deploying Microsoft LAPS – Part 2 appeared first on The Sysadmins.

Issue

You are unable to play HTML5 videos in Internet Explorer 11, the HTML5 player displays a black screen only.

Fix

A post on the MSDN Blog states: In order to play HTML5 videos in the Internet Zone, you need to use the default settings or make sure the following registry key value 2701 under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 is set to 0.

However, when setting the value of 2701 to 0 in this location the value does not stick and reverts back to 3. Process Monitor showed that Group Policy was setting the value to 0, and then back to 3. Despite putting this policy last, and trying various other tactics I was unable to change this behaviour.

To apply this setting, you can also use the following key location: HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3.

When set here, the value of 2701 will not revert back to 3 (disabled), and HTML5 video playback will be enabled.

You can set this via GPP as below.

The post Internet Explorer 11 – HTML5 Black Screen appeared first on The Sysadmins.

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.

The post Group Policy – Removing Internet Explorer Maintenance Settings appeared first on The Sysadmins.

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.

The post SCCM 2012 SP1 – Enable Command Support Console in WinPE appeared first on The Sysadmins.

Problem

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.

Solution

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(0x80040104)

ThreadToResolveAndExecuteTaskSequence failed. Code(0x80040104)

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!).

The post SCCM 2012 – Failed to Resolve Selected Task Sequence Dependencies appeared first on The Sysadmins.

It’s been around a while, but the IT Crowd is well worth watching if you haven’t seen it before- all 4 seasons are up on Netflix. Here’s one of my favourite clips.

The post The IT Crowd appeared first on The Sysadmins.

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 = "//go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x64"
$x64D1 = "\\server\SCEPUpdates\x64\mpam-fe.exe"
$x64S2 = "//go.microsoft.com/fwlink/?LinkId=211054"
$x64D2 = "\\server\SCEPUpdates\x64\mpam-d.exe"
$x64S3 = "//go.microsoft.com/fwlink/?LinkId=197094"
$x64D3 = "\\server\SCEPUpdates\x64\nis_full.exe"
$x86S1 = "//go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86"
$x86D1 = "\\server\SCEPUpdates\x86\mpam-fe.exe"
$x86S2 = "//go.microsoft.com/fwlink/?LinkId=211053"
$x86D2 = "\\server\SCEPUpdates\x86\mpam-d.exe"
$x86S3 = "//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.

The post SCCM 2012 – SCEP UNC Definition Updates Automation with Powershell appeared first on The Sysadmins.

Problem

Find the default gateway on a list of remote servers.

Solution

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.

The post Get Default Gateway from List of Remote Servers appeared first on The Sysadmins.

GPResult is a command-line utility for determining the resultant set of policy for a given user and/or computer. In other words, it shows you what Group Policy Objects have been applied and their settings. This is typically one of the first tools I go to when troubleshooting Group Policy from a client once basic connectivity has been confirmed (e.g. Network/DNS). The tool itself is very simple to use and I will run through some common examples below.

List GPOs Applied with Summary Data

Gpresult /r

/r Displays RSOP summary data

This is pretty useful when you simply want to see what GPOs have applied and in what order. It will also display summary data, such as last time group policy was applied, which Domain Controller it was applied from, the site, security groups and if the slow link threshold has been activated. If you are unsure if a GPO has been applied, this is a quick way of checking.

Here we see that 4 GPOs have applied to the Computer settings portion.

If you don’t want to view both Computer and Users settings in the output you can request one or the other with the /scope flag.

gpresult /r /scope:user

gpresult /r /scope:computer

The output reads fairly well from within the command prompt, but if you need to export the output you could use either of the following.

Gpresult /r > gpresult.txt Export output to a text file
Gpresult /r |clip Export output to Windows clipboard

I can’t see the Computer Settings?

If UAC is enabled, running GPResult without elevating the command prompt will only show you the user settings. If you want to see both user and computer settings, elevate the command prompt by either tapping the winkey+cmd then ctrl+shift+enter or right click on the command prompt and select run as administrator. If you elevate with an admin account different to the currently logged in user (common if the user does not have administrator rights), then you will receive an error message stating INFO: The user “domain\user” does not have RSOP data. This is because GPResult is using the elevated user’s context. To work around this, specify the standard user that you are troubleshooting.

gpresult /r /user:sa\edward.thomas

Generate HTML Report

Gpresult /h report.html /f

Gpresult /h report.html /user:sa\edward.thomas /f

/h Saves the report in HTML format
/f Forces GPresult to overwrite the file name specified with /h
/user Specifies the user name for which the RSOP data is to be displayed

To get a more graphical view of what’s going on, you can generate a HTML report. This gives a detailed break down of each setting and the GPO from which it came. This view is particularly nice as you can show all and use ctrl+f to find a particular policy or setting.

Run GPResult on Remote Computer

Gpresult /s server1 /r

/s Specifies the remote system to connect to

This allows you to run GPResult on a remote system, all of the above applies.

The following GPOs were not applied because they were filtered out

You may see this for a few reasons. The first that the policy is empty in which case you’ll see Filtering: Not Applied (Empty), this is fairly self explanatory. The second is Filtering: Denied (Security), which typically boils down to the “Apply Group Policy” permission on the GPO. You may also see Filtering: Denied (Unknown Reason) which is similar to (Security) in that the “Read” permissions has been denied.

To review the last two examples, launch the GPMC (Group Policy Management Console). Find the offending GPO, and select Delegation- from there you may see an additional group or a single user or machine that has been added.

Click on advanced and review the permissions against the object. In this case you can see that the Seven computer object has been denied Apply Group Policy resulting in the Filtering: Denied (Security) message.

If in doubt, select Advanced -> Effective Access and enter the required computer or user object. If you scroll down to around halfway you’ll see the Apply Group Policy permission with either a green tick of a red cross against it. If deny read has been granted every permission will have a red cross next to it.

I hope this gives you the basics behind GPResult and some good real world example to aid in your Group Policy troubleshooting.

The post Group Policy – GPResult Examples appeared first on The Sysadmins.