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.

Deploying Microsoft LAPS to a non-persistent VDI environment requires a slightly difference approach to traditional machines, especially for those environments that force a reboot after user log off (e.g. Citrix XenDesktop using PVS).

Issue

1. Computer Boots up for the first time after LAPS installation and GPO configuration
2. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed which will read 0 as a password has never been set for given computer
3. New password is set on the Computer, written to Active Directory and the ms-Mcs-AdmPwdExpirationTime attribute is updated giving an expiry date for the password (as per the Group Policy “password age (days)” setting)
4. Computer is restarted and boots the golden image
5. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed, the value is now populated with an expiry time for the password set in step 2
6. Computer does not update password
7. LAPS is not functional

Fix

Originally I looked at clearing the ms-Mcs-AdmPwdExpirationTime attribute on shutdown with VBS.

Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD
objComputer.SetInfo

This can also be accomplished with PowerShell but requires you install the Remote Server Administration Tools which wasn’t desirable. Running the script on shutdown was unsuccessful, due to an issue with how Citrix Delivery Controllers manage the shutdown process of the virtual desktops, essentially preventing the script from running. More information here: Logoff Script is terminated early on XenDesktop.  This may not be an issue for you if you are using another VDI solution.

After trying a few other methods, the following has proven to be reliable. The VBS script sets the ms-Mcs-AdmPwdExpirationTime attribute to 0, waits 3 minutes and then runs GPUpdate to trigger a password update. The 3 minute pause is insurance that the ms-Mcs-AdmPwdExpirationTime change has been replicated to other DCs within the same site. With this method you are essentially setting a new password and expiry date at every startup, maybe Microsoft will add this as a feature in a future release of LAPS.

Add this to a startup script either in Group Policy or locally on the golden image with gpedit.msc and enjoy LAPS within your VDI environment!

LAPSVDI.vbs

Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD
objComputer.SetInfo
' Sleep 3 minutes
WScript.Sleep(180000)
Set WshShell = CreateObject("Wscript.Shell")
' Run GPUpdate force and target only the computer policies
Result = WshShell.Run("cmd /c echo n | gpupdate /target:computer /force",0,true)
' Exit with code
Wscript.Quit(Result)

The post Deploying Microsoft LAPS – Non-Persistent VDI 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.

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.