Wednesday, February 11, 2015

Cisco AnyConnect "Failed to Initialize Connection Subsystem"

I run Windows 8.1 and run Cisco AnyConnect Secure Mobility Client version 3.1.03103 to access a VPN.  After getting the error I updated to the latest AnyConnect Client version 4.0.00061 and got the same result.

Last night I install all of the updates from patch Tuesday (over 1.1G worth including Office 2013 patches).  Today, after I hit connect, it stopped working out of the blue with the error:

Failed to initialize connection subsystem

I suspect a recent Windows update must be the cuplrit.  Here's the steps you will find all over the web to fix it.  THIS DOESN'T WORK!  To fix just uninstall the KB3023607 published for install yesterday!

1. Close the Cisco AnyConnect Window and the taskbar mini-icon
2. Right click vpnui.exe in the “Cisco AnyConnect Secure Mobility Client” folder. (I have it in “C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\”
3. Click on the “Run compatibility troubleshooter” button
4. Choose “Try recommended settings”.
5. The wizard suggests Windows 8 compatibility.
6. Click “Test Program”.  This will open the program.
7. Close

Cisco has escalated this issue to Microsoft for investigation from what I can find.

This issue was introduced by KB# 3023607: Secure Channel cumulative update changes TLS protocol renegotiation and fallback behavior (https://support.microsoft.com/kb/3023607) and included with Microsoft Security Bulletin MS15-009 – Critical Security Update for Internet Explorer (3034682)

This issue is rumored to affect Windows 7 with IE 11 as well.  I have not experienced this myself as I no longer run Windows 7 on any of my machines.


Sunday, December 14, 2014

vMotion Fails at 14% - Operation Timed Out

While working on a 3 host VMware cluster I was trying to vMotion some servers around and begin maintenance and updates.  I hit this error for the first time "Operation Timed Out" and the dreaded red X.

As it turns out there was a vmx-****.vswp file inside the VM folder that apparently was left over from a failed DRS migration.  After doing some research I found out that during a DRS migration the VMX file is started on both nodes.  Once the migration is completed normally one of these gets removed.  In this case it did not.

If you browse the datastore of the VM that will not move and you open up the folder of the VM you should see two vmx-****.vswp files.  If you see only one then you've got another issue and this isn't the fix.  If you do see two they will be .vswp-1 and .vswp-2.  There could be a .vswp for the VM itself.  DON'T DELETE THAT ONE!  I can't stress that enough.

To know which one to get rid of just look at the time stamps.  If the VM is running it may be hard to tell which is which so make sure you turn the VM off before you begin this process.  Once it's off then whichever file remains in the folder is the one you need to delete.

You can try deleting the file using the datastore browser but if that doesn't work then here's how you can remove it.

1. Start the SSH daemon on the host which has the VM registered and then login via SSH.  I recommend Putty.  You can download it HERE along with many other great tools for network and systems maintenance.
2. # cd /vmfs/volumes/{datastore name}
3. # cd {VM folder name}
4. # ls -lash *.vswp (this will show all the files and timestamps just to verify)
5. # rm vmx-{VM name}-[1-2].vswp

That's all there is to it.  Remember to disable the SSH daemon on your host and now you should be able to vMotion the VM again with it running.

Saturday, December 13, 2014

How Long Is Left on Database (IN RECOVERY)

While working on a SQL 2008 R2 database connection error for a medical company I found the database showing (IN RECOVERY).  Naturally no connections could be made during this process.  What I truly needed to know was how to see how long the process has left.  I found this great script HERE.  For my own purposes I decided to list it here as well.

DECLARE @DBName VARCHAR(64) = 'databasename'

DECLARE @ErrorLog AS TABLE([LogDate] CHAR(24), [ProcessInfo] VARCHAR(64), [TEXT] VARCHAR(MAX))

INSERT INTO @ErrorLog
EXEC sys.xp_readerrorlog 0, 1, 'Recovery of database', @DBName

SELECT TOP 5
[LogDate]
,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining
,[TEXT]

FROM @ErrorLog ORDER BY [LogDate] DESC

Update for SQL 2012.  The syntax is a bit different:

DECLARE @DBName VARCHAR(64) = 'databasename'

DECLARE @ErrorLog AS TABLE([LogDate] CHAR(24), [ProcessInfo] VARCHAR(64), [TEXT] VARCHAR(MAX))

INSERT INTO @ErrorLog
EXEC master..sp_readerrorlog 0, 1, 'Recovery of database', @DBName

SELECT TOP 5
[LogDate]
,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining
,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining
,[TEXT]

FROM @ErrorLog ORDER BY [LogDate] DESC

Just copy and paste this script in, change the database name, and you're good to go.

EDIT:  One thing to note is that it may show over 85% and yet if you check the database the process has completed.  I suspect this is because once the recovery is done this information is no longer updated.



Monday, September 08, 2014

Adjust Exchange 2013 Send-Receive Message Size Limits

After setting up and Exchange 2013 SP1 server on Server 2012 R2 I ran into this small issue with a customer.  Even though I had all of the send/receive connectors in the ECP set at 100M, I was still hitting the default 10M attachment size limits.

Here's how to fix that by changing the Global Transport Settings: (short answer)


Check to see what the size limits currently are -

Get-TransportConfig | ft MaxSendSize, MaxReceiveSize

Once you know those sizes then here's the command to change them to what you need -

Set-TransportConfig –MaxSendSize 100MB –MaxReceiveSize 100MB

I know these sizes are a little large but just using them as an example.  Go ahead and bounce the Transport service just to be sure the settings take effect and you'll be good to go.


All of the other size limits can be set using the ECP under Mailflow and then Send Connectors and Receive Connectors.


Update:  I've just completed reading almost all of Mastering Microsoft Exchange Server 2013 .  This is an excellent read that will give you tons of insight into installing, maintaining, and mastering all there is to Exchange 2013.  I highly recommend you give the book a read.

Wednesday, August 06, 2014

How to Disable the 21 Day Timer for SBS 2003, 2008, and 2011

Here’s the process to prevent SBS2003 from shutting down after 21 days of migration have passed. The basic principle is to disable the SBS Core Service (sbscrexe.exe). The problem is when you just turn off the service, it will restart itself automatically. To achieve this goal follow the steps below:
  1. Download process explorer from http://technet.microsoft.com/en-us/sysinternals/bb896653
  2. Run Process Explorer and SUSPEND the sbscrexe.exe file.
  3. Open regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SBCore
  4. Right click the key and click permissions. Give the Administrators group full control on both the key and child nodes.
  5. Refresh the key so you can see all of the registry settings for sbcore and change the Start DWORD value from 2 to 4 to disable the service.
  6. Using explorer navigate to the sbscrexe.exe file in the C:\WINDOWS\system32 directory and change permissions on the file to everyone deny.
  7. Go back to process explorer and kill the sbscrexe.exe process. If it doesn’t start again then you have successfully disabled the file.