Unable to open ILO3 with TLS 1.2

In this case I was unable to connect to ILO3 on HP DL 380 G7 with Internet Explorer 11 from Windows 8.1 client workstation. ILO Firmware version was 1.20. Starting from Windows 8.1 and Internet Explorer 11 all TLS protocols are enabled and supported by default:

ILO was not failing back to lower version of TLS if TLS 1.2 was selected. After unselecting TLS 1.2 from Internet Explorer 11, I was able to connect to ILO interface. This is issue was resolved with later version ILO firmware. So, after patching the server with latest ILO firmware, I was able to connect to ILO3 interface using Internet Explorer 11 with TLS 1.2  selected.
 

Internet Explorer Branding failed

On all Windows 8 and Windows 8.1 client Resultant Set of Polices (rsop.msc) was returning an error for Internet Explorer Branding component like this:

And in Group Policy event log the following event is logged Event ID 7016:

• CSEElaspedTimeInMilliSeconds 0
• ErrorCode 127
• CSEExtensionName Internet Explorer Branding
• CSEExtensionId {A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B} 

The reason for this behavior is that Internet Explorer Maintenance or Internet Explorer Branding has been removed from Windows 8 and Windows Server 2012. One way to resolve this error is to remove Internet Explorer Branding Group Policy client side extension using the following Microsoft KB 2813272 .
Another way to prevent this error is to prevent all the GPOs with some Internet Explorer Maintenance configured setting from applying to Windows 8 computers. But, there is also another catch, if you reset the Internet Explorer Maintenance settings in GPO, the extensions are not removed from GPO ! There is also published article from Microsoft about this bug http://support.microsoft.com/kb/2722241/EN-US . So, there might be GPOs with no settings about internet explorer branding, but still having the client extension in place. To find all the GPOs with configured Internet Explorer Maintenance extension, dsquery can be used with following syntax:

dsquery * -filter "(&(gPCUserExtensionNames=*{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}*))"

DSquery will return GUIDs of all affected GPOs with Internet Explorer Branding Extension. In order to remove the extension information from the GPOs, Active Directory Users and Computers snap-in on Windows Server 2008 or later can be used to edit the attributes. Navigate to Domain Name -> System -> Policies and locate and select the GUID of the GPO that was returned as result from dsquery command, and go to the attribute editor tab from the properties of the GPO. Search for gPCUserExtensionNames entry and edit the field. Locate the [{A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}], and delete that entry including "[" and "]" brackets. Save the properties, and that GPO will not be qualified for running the Internet Explorer Branding client extension.
After removing "orphaned" extensions from GPOs, the Event ID 7016 with error code 127 was not logged anymore and rsop.msc was not returning failed status for Internet Explorer Branding since this extension is not in use anymore.

Note: If you're using Internet Explorer Maintenance for pushing Internet Explorer settings to clients, you should consider migrating to Group Policy Preferences for Internet Explorer for setting those settings. Also, you can't use Internet Explorer Maintenance for setting Internet Explorer 10 or 11 http://technet.microsoft.com/en-us/library/jj890998.aspx .
 

Group Policy Internet Settings Event ID 4098

In this post I'll explain how I've managed to fix the Warning Event ID 4098 from Group Policy Internet Settings source in Application Log. The following event was logged in Application Event Log on affected machines:

The user 'Internet Explorer 10' preference item in the 'Policy Name and ID' Group Policy Object did not apply because it failed with error code '0x80070005 Access is denied.' This error was suppressed.

The reason for this access denied was because Internet Settings preference 'Internet Explorer 10' was running under user's context.

Removing the check mark from common tab for Run in logged-on user's security context (user policy option) has resolved the warning event log. Preference items created either under computer or user part of the GPO are processed under System security context. For more info about configuring common option check http://technet.microsoft.com/en-us/library/cc772371.aspx .
 

Failed to recreate client evaluation task

In this case there was SCCM 2012R2 client that was reported as client that failed check from All Desktop and Server clients. The error message was Failed to recreate client evaluation task :



This SCCM 2012R2 client was installed on Windows Server 2003 R2 were the local administrators have disabled some services and among them was Task Scheduler. After setting the Task Scheduler service to Automatic and starting the service, and restarting the SMS Agent Host service the Configuration Manager Health Evaluation task was successfully created and the client was no longer reported as client that failed check.
 

TechEd Europe 2014 announced

Microsoft has finally announced TechEd Europe 2014 and will be held on 27-31 October in Barcelona, Spain. For more info visit the official TechEd Europe 2014 web page http://europe.msteched.com .

 

Shared Folder Quota Not Accurate

In this case users were complaining that cannot share files in shared folder on Windows Server 2008 R2 file server with quota assigned on that shared folder. The shared folder had hard quota assigned, and according to FSRM (File Server Resource Manager) Quota Management 90% was used. Here is the screenshot showing that only 10MB were available for that folder:

Dir command was running with elevated credentials, and I was gaining same output from dir command when running under SYSTEM account. So, I was suspecting that quota calculation for that folder was not accurate. In order to trigger quota recalculation I was using Dirquota, with following syntax:

dirquota quota scan /path:<Path to folder>

After running this command, FSRM Quota Management was showing that 9X% were free (instead used) and users started to share files without getting notified that are reaching maximum quota limit for that folder.