Monday, September 23, 2013

Internet Explorer 9 Local HTML Files - Do you want to save this file?

A customer of mine just deployed Internet Explorer 9 to their workstations through WSUS.  After rolling out Internet Explorer 9 whenever html files were executed from the local computer users were prompted with:

"Do you want to save this file?"

For this particular customer, the logon script executed a html file locally to show live process of the various tasks the logon script needed to carry out.  Internet Explorer 9 caused major disruption as a result.


To allow HTML files to launch from the local computer without popping up as a download, ensure "Allow active content to run in files on My Computer" to be selected in Internet Options.

 

Wednesday, September 11, 2013

IE 10 Prompting for credentials - Windows Authentication

Today I responded to a customer who has an internal intranet.  The customer has no issues accessing the intranet page from IE7, IE8, or IE9 - However when upgrading to Internet Explorer 10, the users are now getting prompted for username and password using windows authentication even though the user account the user is logged in with has access to the website hosted on Internet Information Services (IIS).

The following screenshot shows the logon authentication prompt presented from Internet Explorer 10 when attempting to access the organisations internal intranet.


Internet Explorer 10 by default allows credentials to automatically pass through to all "intranet" pages, however "internet" pages do not pass through credentials for security reasons.  To see if Internet Explorer is treating the page as an "intranet" page or "internet" page, right click on the page error message (depending if you typed your credentials in or not) and click properties.


In the properties section of the page it will display what zone is currently configured.  As you see below, Internet Explorer is treating the "intranet" page for this customer as an "internet" page and hence the user is getting prompted.


Now one fix for this problem is to simply go to Internet Options, Internet, Custom Level and set the User Authentication --> Logon to "Automatically logon with current user name and password".  Whilst this will solve the problem it will lead to credentials of the current logged in user to pass over the Internet, not such a good idea!


A better fix is to configure your "intranet" page which is being treated as an "internet" page as an "intranet" page within Internet Explorer.  This can be done by going to Internet Options, Local Intranet, Sites, Advanced.


In the advanced page add your local intranet page.

 
Problem fixed - Internet Explorer will no longer prompt for Authentication when accessing the local Intranet.
 
Applying fix to all computers
 
Now you want to apply this configuration to all computers on your domain.  This can be done using Group Policy using the "Site to Zone Assignment List" group policy setting.  This setting is located under:
 
Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Site to Zone Assignment List
 
 
 In this policy setting enter the intranet address you want to add to the Local Intranet settings as we did manually above along with a value.  The values are represented as follows:

1 = Intranet zone
2 = Trusted Sites zone
3 = Internet zone
4 = Restricted Sites zone

As we want to add the site to the Intranet Zone we enter a value of 1.


Upon the next Group Policy refresh, all workstations will now no longer get prompted when attempting to access the Intranet page.

Hope this blog post has been helpful for people experiencing the same problem.

Wednesday, September 4, 2013

Windows Server 2012 WSUS Server Not Downloading Updates

I had just configured a brand new Windows Server 2012 WSUS Server however a problem was experienced where the server was not downloading updates.  It was a freshly deployed WSUS Server which was configured to synchronise against the Microsoft Update Servers.  The WSUS Server was performing synchronisations according to the preconfigured schedule, and the synchronisation log was showing that new updates were successfully synchronised.

Despite this, the WsusContent folder remained empty.

These symptoms are shown in the following screenshot.


The following errors were also experienced in the servers application logs:

Log Name:      Application
Source:        Windows Server Update Services
Date:          4/09/2013 6:28:44 AM
Event ID:      10032
Task Category: 7
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ADM-WSUS-01.domain.local
Description:
The server is failing to download some updates.



Log Name:      Application
Source:        Windows Server Update Services
Date:          4/09/2013 1:22:15 AM
Event ID:      364
Task Category: 2
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ADM-WSUS-01.domain.local

Description:
Content file download failed. Reason: Value does not fall within the expected range. Source File: /d/msdownload/update/software/defu/2013/08/am_base_patch1_160dc153e5db49297bd527404b2c03e540291cbd.exe Destination File: E:\WSUS\WsusContent\BD\160DC153E5DB49297BD527404B2C03E540291CBD.exe.



After leasing with members of the WSUS team it was discovered a bug existed in Windows Server 2012 when using proxy servers which requires authentication, as per my WSUS deployment.


Microsoft has developed a hotfix for this issue which can be downloaded from the following location.  Companies must request the hotfix and Microsoft will email the download link.

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

Only download this hotfix if you are experiencing the documented issue above.

After you install the hotfix a reboot of the WSUS server is required.

Once the hot fix is installed and the system has been rebooted, you must reset the WSUS content repository.  This is because WSUS "thinks" in the SQL database that all updates have been downloaded when in fact they failed.   To do this perform the following steps:

1) Close any open WSUS consoles.
2) Go to Administrative Tools – Services and STOP the Update Services service.
3) In Windows Explorer browse to the WSUSContent folder (typically D:\WSUS\WSUSContent or C:\WSUS\WSUSContent)
4) Delete ALL the files and folders in the WSUSContent folder.
5) Go to Administrative Tools – Services and START the Update Services service.
6) Open a command prompt and navigate to the folder: C:\Program Files\Update Services\Tools.
7) Run the command WSUSUtil.exe RESET


As soon as you run the WSUSUtil.exe reset command, this command takes a while to complete.  Unfortunately there is no progress bar or message which lets you know the reset has completed.  A handy trick is to monitor the Windows Internal Database SQL Instance for WSUS, this is busy with high CPU activity as it checks every update in the SQL database against the files in the WsusContent folder.  As soon as the SQL activity dies down you know the command has completed.


After this perform another sync.  You will then notice the WSUS Server begin to download the updates by verifying the WSUSContent directory growing.

 
Please not the WSUSContent takes a long time to download and will most likely pause consistently through the download process.  As soon as you verify the content size is growing, log off the server and leave it for 24 hours.

Tuesday, September 3, 2013

New Database Created - Couldn't mount the database that you specified

This is a common problem in Exchange 2010 which I have seen multiple times so I have decided to blog it.  When creating a new mailbox database, directly after mailbox creation you might receive the following error:

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
Failed to mount database 'Database2'.

Database2
Failed
Error:
Couldn't mount the database that you specified. Specified database: Database2; Error code: An Active Manager operation failed. Error The database action failed. Error: Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [Database: Database2, Server: ADM-EXCH-01.domain.local].

An Active Manager operation failed. Error The database action failed. Error: Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [Database: Database2, Server: ADM-EXCH-01.domain.local]

An Active Manager operation failed. Error Operation failed with message: MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)
. [Server: ADM-EXCH-01.domain.local]

MapiExceptionNotFound: Unable to mount database. (hr=0x8004010f, ec=-2147221233)


This error can be caused when multiple domain controllers exist in the same Active Directory site.  Microsoft Exchange creates an object in the configuration partition to represent the mailbox database.  When Active Manager goes to mount the newly created database it may talk to a different domain controller in the same Active Directory site which does not yet contain the record for the mailbox database.

These databases objects in Active Directory are msExchPrivateMDB class objects and reside under:

Configuration Partition --> Services --> Microsoft Exchange --> Exchange Org Name --> Administrative Groups --> Exchange Administrative Group (FYDIBOHF23SPDLT) --> Databases

In the event you receive this error simply wait a few minutes for AD Replication to catch up and then attempt the database mount operation again. 

Exchange 2010/2013 - Get-MailboxStatistics TotalItemSize in Numeric Format

To get a list of all mailboxes and their sizes, the following command produces this information.

Get-Mailbox | Get-MailboxStatistics |  select-object DisplayName,TotalItemSize

However the data outputted by this command is not in a format which can be used with script, it is not numeric as shown in the following screenshot.


To get the data for TotalItemSize just as a number such as KB, MB, GB etc, use the following commands:

{$_.TotalItemSize.Value.ToKB()}
{$_.TotalItemSize.Value.ToMB()}
{$_.TotalItemSize.Value.ToGB()}

For example:

Get-Mailbox | Get-MailboxStatistics |  select-object DisplayName, {$_.TotalItemSize.Value.ToMB()}

This will ensure the data returned is in a format which you can use for scripting.

Monday, September 2, 2013

Windows XP - End of Life Risk

Microsoft has announced that Windows XP will become end of life April 8, 2014 which means no more critical or security updates.  Despite this many organisations still do not have a clear plan in place on how to get client computers off Windows XP before this date.

As a an IT Professional I believe come April 8, 2014, companies still running Windows XP will be hit with a large spread of zero day exploit viruses - something which will go down in history.  For those of you who remember all the hype in the media regarding Y2K bug with the clocks ticking over to a new century and the computers no longer working - whilst there was an impact with the clocks turning over the impact was relatively low.  However with the Windows XP end of life date, I believe this is a huge risk which can cause billions of dollars of productivity loss.  Despite this huge risk, there has been little media coverage around it.

I have just made some very big statements such as "Chaos" and "Billions of dollars of productivity loss" - now I need to explain the facts behind my beliefs.

Today as of this writing there are over 21 million viruses according to virus definition signatures provided by lead anti-virus companies such as Symantec corporation.  Most of these viruses need to be executed on a workstation for infection to take effect - a virus will do nothing if the code is not executed!  There are numerous methods cyber criminals trigger unwanted code execution for viruses some including:
  • Fake Ads and URL Links which lead to viral code executing
  • Autorun files and USB keys which automatically run on the users workstation
  • Peer to Peer applications which spread viruses to individuals
  • Mass emailing worms which spread viral code through the use of email attachments
  • Microsoft office files which contain macro virtual code
All these methods of infection trick or silently execute viral code on user workstations to install the virus.  As all means are legitimate ways of launching code on computer systems and as a result companies can put in place methods which circumvent viruses being installed including:
  • Removing the local admin rights which ensure viruses do not have permissions to infect beyond the users profile.
  • Disabling autorun from computers to stop USB viruses from spreading
  • Putting in place advanced spam filtering technologies to ensure viral attachments are not executed.
  • Pushing out enhanced security policies to workstations on the network.
Out of the 21 million viruses, only a handful have been known as malicious zero day exploits.  Zero day exploits are viruses which exploit an operating system vulnerability to automatically copy themselves from computer to computer over a network providing security and anti-virus companies with zero days to prepare.  Zero day exploits generally perform Buffer Overflow attacks creating vulnerabilities in core system services by overwriting adjacent memory blocks outside of an applications working set.  When the system goes to call code in memory, the code has altered and as a result it executes miscellaneous code which creates a system vulnerability to infect a machine.

The only way to stop a zero day exploits is to patch the security vulnerability in the operating system to ensure the zero day exploit can no longer buffer overflow the vulnerability in the operating system/application.

Over the years there has been a number of zero day exploits which have hit including Conficker, MS Blaster and Stuxnet - a computer worm discovered in June 2010 that is believed to have been created by the United States and Israel to attack Iran's nuclear facilities.  All these viruses were able to spread by performing buffer overflows to simply hop from computer to computer bypassing corporate security measures.

Finding a zero day exploit in an operating system is a difficult task which can take months or years of testing and reverse engineering of compiled code.  Cyber criminals spend large amounts of time researching and performing trial buffer overflows until the right exploit can be identified which can trigger remote code execution.  As soon as the buffer overflow is identified, it can only be used once.  As soon as it is used IT security companies become aware and software companies such as Microsoft patch their software making the buffer overflow useless.

As a result these zero day exploits are worth a lot of money to the right buyer and there is no doubt there are many out there which have been identified but not yet been used.  This can be shown in the following article "Microsoft Said To Give Zero Day Exploits To US Government Before It Patches Them":

http://www.techdirt.com/articles/20130614/02110223467/microsoft-said-to-give-zero-day-exploits-to-us-government-before-it-patches-them.shtml

With the end of Windows XP date becoming so close, it is unlikely we will see many zero day exploits be released unless it is for a targeted purpose such as Stuxnet.  After the Windows XP end of life date I believe we will see a large number of exploits appear for Windows XP and no backing support from Microsoft.  Who knows, if I am correct and the world is hit by a large number of zero day exploit attacks against Windows XP after the end of life date, Microsoft may be forced to go back on this announcement and fix these patches.  If this happens, as for Windows XP, we may be seeing this around for years to come yet...

In summary I believe it is a huge risk to organisations to maintain Windows XP workstations after the April 8, 2014 deadline.  The best thing to protect your business is to get off Windows XP now!

It will be very interesting to see what happens...