Windows Media Player 12 Crash with EMET 5.0

Posted by Ahmed Nabil | 0 comments»
I am currently running Microsoft EMET (Enhanced Mitigation Experience Toolkit) version 5.0 (Latest Version) with the popular software list which protects other well known software as Google Chrome, Firefox, Windows Media Player............etc.

After upgrading EMET to the latest version 5.0, I noticed that the Windows Media Player (Latest Version 12) crashes and the below event log is reported.



My first suspect was EMET, I removed all mitigation for the Windows Media Player from the Apps Section as shown below.



Windows Media Player started working normal after removing all mitigation, I started checking them one by one till it crashes back again with the StackPivot Mitigation.

The StackPivot Mitigation is used to detect if the stack is pivoted and used to validate the stack register present in the context structure of certain APIs. For some reason its triggered with Windows Media player and you need to un-check it to work it out till Microsoft finds a solution since they are both Microsoft Products.



UAG Direct Access client Fail to connect. DA is configured and disabled.

Posted by Ahmed Nabil In , | 0 comments»
I got couple of users using Windows 7 reporting that they can't connect using Direct Access anymore whether its HTTPS or Teredo, DA just won't work. Upon further discussing the issue with them they mentioned that they enabled and disabled the Direct Access Connectivity assistant (DCA) Use Local DNS couple of times in an effort to work it out.

We started troubleshooting by checking the Name Resolution Policy table and we noticed that the NRPT was not getting applied on the DA client as shown below.





The next step was checking the DA resolution using the netsh dns show state command and it turned to be disabled.


Name Resolution Policy Table Options
--------------------------------------------------------------------

Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                        if the name does not exist in DNS or
                                        if the DNS servers are unreachable
                                        when on a private network

Query Resolution Behavior             : Resolve only IPv6 addresses for names

Network Location Behavior             : Never use Direct Access settings

Machine Location                      : Outside corporate network

Direct Access Settings                : Configured and Disabled

DNSSEC Settings                       : Not Configured


The DA client already has the correct group policies, certificates but its disabled.

The next step was checking the below registry key:

"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient EnableDAForAllNetworks"

The value of the key was set to 2 which means that DA is disabled !

Upon deleting the registry key, the DA started working normally without any problem.

For more information about the EnableDAForAllNetworks and its different values please check the below URL. 


On both cases that i have seen so far the reason was playing with the DCA settings (Use local DNS) which triggered the flipping of this registry key from Automatic to disabled.


Hopefully this could help someone with the same problem.






Publish RDS 2012 R2 VDI Pool on Microsoft UAG 2010 SP4

Posted by Ahmed Nabil In | 0 comments»
Unfortunately there is no much information (almost nothing) available from Microsoft regarding publishing Virtual Desktop Infrastructure (VDI) Pool on Microsoft UAG 2010. Two years ago i published an article on this same topic but it was targeting publishing the VDI pool from 2008 R2 Virtualization Host server to UAG 2010. You may check it on the following link http://itcalls.blogspot.com/2012/05/publishing-microsoft-pool-vdi-on-uag.html

Lately we updated all our Remote Desktop services servers and upgraded everything to 2012 R2 including the VDI pool (Updating the pool with Windows 8.1 machines). I followed the same steps in my previous article but it didn't work.

The main trick is that in the old RDS version 2008/2008R2 the Session Host (RDSH) was the redirection server. This architecture changed in 2012/2012 R2 servers and the Connection Broker is the component that do the redirection (RDCB).

Since publishing the 2012 R2 VDI is not officially certified with UAG 2010 and to get around this issue,  our team checked the below old article to bypass checking resources.

http://support.microsoft.com/kb/2702989

All We need to do is to adjust the Registry key on the UAG server as shown below:

HKEY_LOCAL_MACHINE\Software\WhaleCom\e-Gap\Common

DWORD Value: TSDontCheckResources
Value data: 1


So what does this Registry key will actually do ?

When connecting to the Remote Desktop Server, the Broker returns the resources list it receives from the RDSH and it picks up all IP addresses on all interfaces on the server. Now the UAG server needs to resolve all the IP addresses returned in the resource list to names and verify if they resolve to the same server. If the resource list contains IPV6 addresses, this lookup fails and hence the security check fails and the connection fails to launch one of the VDI machines in the pool.


To Make it work, i followed my earlier article and then added this key and its working fine.






Event 1096, The Processing of Group Policy failed.

Posted by Ahmed Nabil In | 0 comments»
Recently i came across a group policy processing failure when a user tries to do a gpupdate /force, it works for the User Policy and fails for the computer policy with an error that group policy failed processing. As a result any computer policy on this device will fail.

Upon checking the Event viewer, the system log was filled with the Event ID 1096 as attached below.


As per the Event ID 1096, Windows couldn't apply the registry-based policy settings for the LocalGPO. The first place to check was the Registry.pol file located locally on the computer.


Steps to resolve this issue:


  1. Delete or rename the registry.pol file under c:\windows\system32\grouppolicy\machine\registry.pol
  2. Configure any administrative template settings in the local Computer settings GPO. This will re-generate automatically a new registry.pol file.
  3. Gpupdate /force will run normally without any problem.

For more info about Local GPO and corrupted Registry.pol, please check the below links:






EMET detected Caller mitigation and will close the application: Chrome.exe

Posted by Ahmed Nabil | 0 comments»
Recently users with EMET 4.1 installed on their machines started getting problems with Google Chrome. When users try to open Google Chrome they get an EMET Caller mitigation violation and Chrome crash and get closed. The Following event will be logged in the Application Event Viewer.


This issue started Late May, 2014 (20/21) after Google released the latest version of Chrome (35.0.1916.114). This issue was addressed on several other sites as Chromium http://www.chromium.org/Home/chromium-security/chromium-and-emet

as well as EMET Application compatibility Forum http://social.technet.microsoft.com/Forums/security/en-US/1e70c72b-67b2-43c4-bd36-a0edd1857875/application-compatibility-issues?forum=emet

The temporary Solution for this issue was to remove the Google Chrome from the list of Protected applications in EMET or disabling the caller mitigation for Chrome.exe.

Final Resolution:

Microsoft Released EMET 4.1 Update 1 on 29/5/2014 http://www.microsoft.com/en-eg/download/details.aspx?id=41138

This update added new functionality and updates which includes fixing this compatibility issue and other false positive reporting as per attached documentation.



After applying this update and rebooting the machine users were able to open the Chrome.exe without any problem.

Note: When applying this update make sure to keep your existing settings.






Users Expired Certificate Warning-Lync Certificate

Posted by Ahmed Nabil In , | 1 comments»
Several users started receiving certificate expiration warning messages on their computers regarding specific user certificates. Upon checking this certificate it turned out to be Lync Communication certificate as per the below screen shot.




This message is a normal Windows Warning Notification regarding a user certificate stored in the personal certificate store of the user account logged on this machine. In this specific case it was Microsoft Lync Communication certificate. When the Lync communication certificate expires, the client will just receive new certificate for the user SIP URI and everything should work normal.

However to manually stop receiving the warning shown above the user can check the box near the certificate and click done.

The question is why all users in the domain started getting these warning messages. To identify the root cause, i ran a GPRESULT from one of the client computers and i noticed a group policy configured across the domain with these warning settings. These specific settings are located under

User Configuration/Windows Settings/Security Settings/Public Key Policies/Certificate Services Client – Auto-Enrollment Settings”


There is a checkbox as shown below for the Expiration Notification when the the given percentage of certificate lifetime is reached. To avoid getting these warning you can remove/uncheck this option and users won't receive this notification.



It should be noted that if there is no group policy set, the users won't get any notification and won't even notice that the certificate expired and they got a new one.




مايكروسوفت EMET 4.1 - الجزء 1

Posted by Ahmed Nabil | 0 comments»
Microsoft EMET 4.1 tool Part 1 for Basic Installation and configuration in Arabic



Force Log off of idle Remote sessions on Server 2008 R2

Posted by Ahmed Nabil | 0 comments»
Normally IT users will connect to the servers using RDP/MSTSC to administer and configure their servers, However they will mostly leave their sessions and forget to log off after doing their work especially if its long task or they are used to connect to these servers on regular basis. This can cause several security issues as well as account problems especially if the user changed his password while there is a session logged on another sever.

You can easily Force log off of idle sessions on remote servers by creating a scheduled task on these servers. In the below example i would assume forcing idle sessions to log off after one hour.

To create the needed task you need to do the following:

  1. Open the Task Scheduler, Click Task Schedule library
  2. Create New Task
  3. Type the name of the task and select "Run with Highest Privilege" check box                                                                                                                                                                                          
  4. On the triggers click New and check "On Idle"                                                                                                                      
                                                   
  5. From the Actions, Click New and choose the logoff.exe (The default path of the logoff.exe is C:\Windows\System32)                                                                                                                                           
                                                         
  6. In the Conditions Tab, Set the idle time. In this example, the idle time is 1 Hour.                                                                               
                                                   
Its a simple solution but would fix the problem of several idle connections on the server blocking other users to connect (I am mainly talking about normal servers with no Terminal server role installed where you have only two sessions available for remote users).






SCOM Event 26004, Health Services Module. Hyper-V Image Management Service admin Event Log

Posted by Ahmed Nabil In , | 0 comments»
I was working lately on Migrating and moving all our Virtual Machines from Hyper-V 2008 R2 Hosts to the latest 2012 R2 Hyper-V Hosts. We installed the Hyper-V 2012 and 2012 R2 SCOM Management Packs to monitor our new servers while keeping the old 2008 Hyper-V Management Pack since there are still VMs hosted on 2008R2 (Transition Phase).

It was noticed that Event ID 26004 is repeated on daily basis on my Hyper-V 2012 R2 Host servers under the Operations Manager logs from Server Event Viewer.



The Image Management Service Admin Event log was only available back in Hyper-V 2008 R2 Hosts and it doesn't exist in Hyper-V 2012 or 2012 R2



Problem

On my SCOM server i have three Hyper-V Management Packs for 2008R2, 2012 and 2012R2 Hyper-V hosts. Logically each Management Pack should identify and point all its monitors to its relevant servers. However it looks like the 2008R2 Management Pack which includes the Image Management Service admin Event log is pointing and trying to get this data from the 2012 and 2012 R2 servers

Upon checking this issue with several Microsoft Support engineers, they confirmed that when the 2008 R2 Management Pack was created the work flow was targeted very broadly and affected all Hyper-V hosts, Even if you have the correct Management pack as 2012 or 2012 R2, this won't stop the 2008 MP to monitor and target the newer Hyper-V servers.

Solution

The Solution is to disable targeting this monitor from the 2008 MP to 2012 and 2012 R2 servers

In order to do this you need to do the following:

1. Go to the SCOM Console, Authoring - Management Pack Objects - Monitors - find - mounted drive



2. To confirm that this Monitor although is 2008 its targeting also 2012 and 2012 R2 you need to check from the SCOM Console the Monitoring - Discovered Inventory and change Target type to Hyper-V Virtual Hard Disk, you will find all Hyper-V servers are listed and not only 2008 R2 Hosts.

3. From the Authoring - Groups -create new group, select a name and place it in new customized Management Pack.

4. In the Explicit Members - Click add/remove object. Add all 2012 R2 and 2012 Servers and disks (Search for Hyper-V Virtual Hard Disk and Widows server 2012/2012 R2 Full computer)



5. Right Click the SCOM Monitor (Hyper-V Virtual Hard Disk - Mounted drive Read-Only ), disable the monitor - For a group and pick the group created in Step 3. Enable & Enforce the Override as per attached.







This should fix the problem. Also if all VMs are migrated lately to 2012 R2 or 2012 Hosts and there is no more 2008R2 Hyper-V hosts in the environment, you can delete the 2008 Hyper-V Management Pack from SCOM to avoid this issue or similar ones.