Category: Computers and Internet

Internet Explorer (IE) – “Continue to this website” option is missing

With the new update (KB2661254), Microsoft is started blocking the websites with certificate key length is 1024 or less. With this IE will never let you connect to site at all. All you get is “Click here to close this webpage”.


Fortunately Microsoft explained how to override this security feature in the same KB article (


  1. Open Command Prompt with Administrative Privileges (right click CMD.exe and select “Run as administrator”)
  2. Type certutil -setreg chain\minRSAPubKeyBitLength 512
  3. Log off and log back in

Here is the resolution by editing the registry key from the KB article:

Allow key lengths of less than 1024 bits by using registry settings
Microsoft does not recommend customers use certificates less than 1024 bits long. Customers may however need a temporary workaround while a longer term solution is developed to replace RSA certificates with a key length of less than 1024 bits length. In these cases, Microsoft is providing the customers the ability to change the way the update functions. Customers configuring these settings are accepting the risk that an attacker may be able to break their certificates and use them to spoof content, perform phishing attacks, or perform Man-in-the-Middle attacks.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 How to back up and restore the registry in Windows
On Windows 8 or Windows Server 2012-based computers that have the update applied, the following registry path and settings can be used to control detection and blocking of RSA certificates with less than 1024 bit key lengths.

HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\OID\EncodingType 0\CertDLLCreateCertificateChainEngine\Config

There are four main values that control how keys under 1024 bits blocking works. These are as follows: •MinRsaPubKeyBitLength
Each of these values and what they control are discussed in the following sections.

For operating systems starting with Windows Vista and Windows Server 2008, you can use certutil commands to change these registry settings. On Windows XP, Windows Server 2003, and Windows Server 2003 R2, you cannot use certutil commands to change these registry settings. However, you can use Registry Editor, reg command, or reg file.
MinRsaPubKeyBitLength is a DWORD value that defines the minimum allowed RSA key length. By default, this value is not present, and the minimum allowed RSA key length is 1024. You can use certutil to set this value to 512 by running the following command:

certutil -setreg chain\minRSAPubKeyBitLength 512

NoteAll certutil commands shown in this article require local Administrator privileges because they are changing the registry. You can ignore the message that reads “The CertSvc service may have to be restarted for changes to take effect.” That is not required for these commands because they do not affect the certificate service (CertSvc).

You can revert to blocking keys that have a length of less than1024 bits by removing the value. To do this, run the following certutil command:

certutil -delreg chain\MinRsaPubKeyBitLength
The EnableWeakSignatureFlags DWORD value has three potential values: 2, 4, 6, and 8. These settings change the behavior of how the keys under 1024 bits detection and blocking works. The settings are described in the following table:

Decimal value Description
2 When enabled, the root certificate (during chain building) is allowed to have an RSA certificate with a key length of less than 1024 bits. Blocking of RSA certificates lower in the chain (if they have less than 1024 bit keys) is still in effect. The flag enabled when this value is set is as CERT_CHAIN_ENABLE_WEAK_RSA_ROOT_FLAG.
4 Enables logging, but still enforces blocking of RSA certificates with keys less than 1024 bits. When it is enabled, the WeakSignatureLogDir is required. All keys with less than 1024 bit length encountered are copied to the physical WeakSignatureLogDir folder. The flag enabled when this value is set as CERT_CHAIN_ENABLE_WEAK_LOGGING_FLAG.
6 When it is enabled, the root certificate is allowed to have an RSA certificate with a key less than 1024 bits and the WeakSignatureLogDir is required. All keys below the root certificate that have keys of less than 1024 bits are blocked and logged to the folder that is specified as the WeakSignatureLogDir.
8 Enables logging and does not enforce blocking of keys that have a length of less than 1024 bits. When it is enabled, the WeakSignatureLogDir is required. All keys encountered that have a length of less than 1024 bits are copied to the physical WeakSignatureLogDir folder. The flag enabled when this value is set is as CERT_CHAIN_ENABLE_ONLY_WEAK_LOGGING_FLAG.

To enable an RSA root certificate that has a key length of less than 1024 bits, use the following certutil command:

certutil -setreg chain\EnableWeakSignatureFlags 2

To enable logging while still blocking certificates that use a key length of less than 1024 bits, use the following certutil command:

certutil -setreg chain\EnableWeakSignatureFlags 4

To enable logging of only RSA certificates below the root certificate that have a key length of less than 1024 bits, use the following certutil command:

certutil -setreg chain\EnableWeakSignatureFlags 6

To enable logging only and not blocking key lengths of less than 1024 bits, use the following certutil command:

certutil -setreg chain\EnableWeakSignatureFlags 8


Outlook 2013: Something unexpected went wrong with this URL–Class not registered


If you get this error when you click on links in Outlook emails, you would be wondering what’s this error is all about.


There is nothing to it. Internet Explorer (or your favorite browser) is not correctly set as default browser for the HTTP/HTTPS links.

Solution: Make IE (or Firefox or Chrome) as default browser on your computer at Control Panel / Default Programs console. This error will go away after you set your favorite browser as default.

Try making Firefox or Chrome as default browser using built-in methods in the browser.  For example, in Firefox the settings are at Options as below.


PowerShell 3.0: How to get Office 365 Service Health alerts in email? (from RSS feed)

Microsoft has awesome Office 365 Admin app on iPhone, Android and Windows phones. But I came across some old school IT guys wants to see Office 365 cloud service alerts in emails. So I wrote a PowerShell script with Invoke-RestMethod cmdlet. Feel free to reuse this script to your needs.

Before you start using this script, you need two things. Office 365 Service Health RSS URI for your organization and a SMTP server to send emails out.

To get the Office 365 Service Health RSS URI:

1. You need to log in to Office 365 with administrator account.
2. Expand and Go to Service Health/Service Health Page.
3. click on RSS icon on top right (see picture below).


O365ServiceHealth O365ServiceHealth1


4. Copy the whole RSS address URI from the Address bar, and keep it in a notepad



Now here is my script. Copy and paste the RSS URI into the script to replace Value for the variable $URI. Change the From/To/SMTP server address in the script. Save the script and schedule it to run every day (or hour, etc.,).

Your download this script from here: Office365Monitor.ps1

Function: Send-Email
Parameters: FromAddress,ToAddress, Subject, Body,
Attachment (array of files)
Purpose: Send email to specified email address
with given subject, body and attachments

Written by: Anand, the awesome, Venkatachalapathy
Function Send-Email()
Param (
$fromaddress = “”,
$toaddress = “”,

$Subject = “Action Required”,
$HTMLBody = $false,
$attachment = @(),
$smtpserver = “”

$message = new-object System.Net.Mail.MailMessage
$message.From = $fromaddress

if ($toaddress.Length -gt 0)
{ $message.To.Add($toaddress) }

$message.IsBodyHtml = $HTMLBody
$message.Subject = $Subject

$attachment.foreach( {
$attach = new-object Net.Mail.Attachment($_)
} )

$message.body = $body
$smtp = new-object Net.Mail.SmtpClient($smtpserver)
# End of Send-Email Funcation

* * * * The Script Starts here * * * *
Script: Office365Monitor.ps1
Purpose: Get Office 365 Service health alerts in
email (from RSS feed)

Usage: Find out your RSS alert URI by
1. logging in to your Office 365 portal
as administrator,
2. go to “Service Health”section,
3. click on RSS icon on top right,
4. Copy and paste the address (URI) to
this script below for value for $URL variable

Don’t forget to change the from/to/smtp server
addresses in this script.

Written by: Anand, the Awesome, Venkatachalapathy
Written Date: Jan 2015

#URI from Office 365 service health RSS section
$URI = “”

#Get the REST representation resource from Office 365 RSS URI
$O365Status = Invoke-RestMethod -Uri $URI

$Alerts = “”

#Collect all degraded service information
foreach($Status in $O365Status)

if ($Status.Description -like ‘*degradation*’)

$Alerts += $Status.pubDate + “`n” + $Status.title + “`n” + `
$Status.description + “`n” + $ + “`n`n”


#send email
if ( $ExchAlerts.Length -gt 10)
Send-Email -fromaddress “” `
-toaddress “” `
-Subject “Office 365 Service is degraded” `
-body $Alerts -HTMLBody:$true `
-smtpserver “”

* * * * The Script Ends Here * * * *

Exchange 2010/2013: Database Context Index Status Failed

According to this KB article KB2807668, Exchange 2013 database content index fails due to missing AD Group named ContextSubmitters. The KB says,

This issue may occur if the search platform tries to check its membership in a security group that is named “ContentSubmitters.” This group is not created by the search platform or by Exchange Server 2013 and is therefore not usually present. Although the check usually fails silently, without any consequences, an exception sometimes occurs. This causes the search component to fail.

The solution from the KB is

To resolve the issue, do the following:

  1. Create a new Active Directory group that is named “ContentSubmitters” and then grant Admistrators and NetworkService full access to the group. This is a dummy group and should be used as a placeholder only. You might want to add a description so that the group is not removed.
  2. Force or wait for Active Directory replication.
  3. Restart the following services:
    • Microsoft Exchange Search
    • Microsoft Exchange Search Host Controller

Now if it is not the issue, you can fix the content index status by updating database copy, using following command on only on failed databases on Exchange Shell.

Get-MailboxDatabaseCopyStatus * | where {$_.ContentIndexState -eq "Failed"} | Update-MailboxDatabaseCopy -CatalogOnly


PowerShell: Find a user or group is member of local Administrators group of a Remote computer

I wrote this script to scan all computers and find if specific Group is member of local administrators group or not. In a day, I found this specific group has local admin access to which computers.

You may modify or use as it is of the following PowerShell script if you need to find the local administrators group membership of a user or group.

    PowerShell Ver 3 or above

    Script: Verify-LocalAdminMembership
    Parameter 1: Computer Name or IP Address
    Parameter 2: Which User or Group to check member of the local Administrators in give computer (param 1)

    Description: This script checks the given user or group is member of local administrators group of the
    given computer or not.

    Written by: Anand, the awesome, Venkatachalapathy


Param ($CompName,$TargetObject)

    Function: IsAdministrator
    Parameter: Computer name of IP Address
    Description: This function checks the membership of local administrators group. If the given
    $targetobject is member of local administrators group, it return True.
function IsAdministrator($hostname)
    $objGroup = [ADSI](“WinNT://$hostname/Administrators”)
    $members = @($objGroup.psbase.Invoke(“Members”))

    $IsAdmin = $false
    $members | foreach { $member = $_.GetType().InvokeMember(“Name”, ‘GetProperty’, $null, $_, $null); if ($member.Equals($TargetObject)) { $IsAdmin = $true } }
    Return $IsAdmin

    —- The Script Starts Here —-
$ReturnValue = IsAdministrator -hostname $CompName

If ($ReturnValue)
    if (($CompName.ToCharArray() | Where-Object {$_ -eq ‘.’} | Measure-Object).Count -eq 3)
        # $CompName contains a IP address, find the hostname from DNS
        $NameOftheHost = ([System.Net.Dns]::GetHostbyAddress(“$CompName”)).Hostname
        $NameOftheHost = $CompName
    “$NameOftheHost contains $member in local administrators group”

Exchange: How come disabled user is still sync emails (on a phone)?

There was an issue raised a terminated user is still sending and receiving emails from his/her phone. We checked the user account was disabled (for sure). How the heck the user still sending emails to us?

Quick search points to this KB: EAS devices still sync after an account is disabled or a password is changed

That is not right!  The solution described as

Any of the following methods will force the device to reconnect on a new connection.

Reset IIS

  1. On the Client Access Server(s) that the device connects to, click Start, click Run and type CMD and then press ENTER.
  2. Type iisreset and press ENTER.

This will restart IIS services.  You can also use the Services.msc snap-in to manually Restart the IIS Admin service.

Recycle the Application Pool used by ActiveSync

  1. Click Start, click Administrative Tools, click Internet Information Services (IIS) Manager.
  2. Expand the server name.
  3. Click Application Pools.
  4. Right click the MSExchangeSyncAppPool and click Recycle.

We can’t do this every time an employee leaves the company (contractors and consultants more frequently). This is destructive change for disabling for every leaving employee.

This blogger had some ideas:

But still it’s not enough. I needed more complete solution without the destructive part. I found such a solution in Technet Blogs.

The following Microsoft Technet Blogs covers the issue and solution. Either you do one-off basis for a disgruntled employee or add it to your termination process for every employee, you can do the following.

BUT, it will still take about 10 to 15 minutes. I would add Active Directory Replication to sync all DCs with this command: Repadmin /SyncAll /AeP from where you disabled the user account and Exchange server resides.

1. Disable Active Sync devices (all of them) for the user

Note down all device IDs from this command output:
Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs

Disable all ActiveSync Devices:
Set-CASMailbox -Identity <user> -ActiveSyncBlockedDeviceIDs “<DeviceID_1>,<DeviceID_2>”

2. Disable OWA/ActiveSync and Mapi on the account

Disable Web Services:

Set-CASMailbox -Identity <user> -OwaEnabled $false
Set-CASMailbox -Identity <user> -EwsEnabled $false
Set-CASMailbox -Identity <user> -EwsEnabled $false
Set-CASMailbox -Identity <user> -EcpEnabled $false

Disable MAPI:

Set-CASMailbox -Identity <user> -MapiEnabled $false
Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true
Set-CASMailbox -Identity <user> -EwsAllowMacOutlook $false
Set-CASMailbox -Identity <user> -EwsAllowOutlook $false

3. Set the Recipients Limits to 0
Set-Mailbox -Identity <user> -RecipientLimits 0

4. Disable the Mailbox and User Account

Here are the blogs for the source of above info:

Part I : Disabled Accounts and ActiveSync Devices Continuing to Sync

Part II: Disabled Accounts and Users Still Being Able to Access via Outlook & OWA