Blog

Since the Poodle vulnerability resulted in SSL v3 to be disabled in web browsers, it broke connectivity to APC devices configured to use SSL. [more]

Using Firefox, you can type in about:config in the web path to enter an advanced configuration mode. The default value of security.tls.version.fallback-limit and security.tls.version.min is “1”. Setting this to “0” will allow you to be able to connect again, but be careful about having SSL connectivity enabled.

I recently migrated a pair of ATMs from behind a Microsoft Threat Management Gateway to a Cisco ASA.  During this cutover, the change was done very quickly so the VPN traffic for the ATMs was not interrupted. [more]

A few weeks later the ATMs started having problems when the Internet connection was disrupted. The VPN tunnels were connected, but the ATM provider was receiving reset packets from the ATMs. I discovered the ATMs were communicating with the ATM provider using TCP port 2000.

Normally TCP 2000 is used by the Cisco Skinny Client Control Protocol (SCCP) and traffic inspection for SCCP is enabled on the ASA by default.  The packet resets stopped after removing SCCP inspection from the global policy list.

To disable SCCP inspection on the ASA:

CiscoASA# conf t

CiscoASA(config)# policy-map global_policy

CiscoASA(config-pmap)# class inspection_default 

CiscoASA(config-pmap-c)# no inspect skinny

After switching to a Thinkpad T440s I started having display problems with Office applications. It would start as a minor issue but end up getting refreshed into a major display problem, which made most of a message or document unreadable. [more]

I found a blog entry at http://blogs.technet.com/b/rmilne/archive/2014/07/08/outlook-2013-distorted-display-issues.aspx that provided a workaround until the Thinkpad display drivers are fixed; disabling hardware graphics acceleration. This is accomplished from within the Office application by going to File -> Options -> Advanced -> Display and check the box to “Disable hardware graphics acceleration.

Registration for the new “.bank” domains is coming up soon. These domains could be prime Internet names in the future. A few quick notes: [more] 

• Early “sunrise” registration will be May 18, 2015 with general availability on June 24th.
• Registration will be limited to domain names with corresponding trademark, trade name, service mark, or bank name. 
• There will be a verification procedure to ensure these domain names are only issued to valid financial institutions.
• Banks should consider registering a trademark now to be able to register the associated domain during the sunrise registration period. 
• Registration will be on a “first come, first serve” basis, so if a bank with similar names want the good domains, they need to register early.
• More information is available at https://www.ftld.com

 

One of our customers reported their Veeam backups were failing. We determined the cause to be the vCenter services were stopped and would not restart. The vCenter issue was a result of the SQL Express database having grown to its 10GB maximum size. We were able to get the vCenter services running temporarily by purging performance data from the database using the procedure at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007453. [more]

This procedure removed enough data to get the services running, but didn’t reduce the overall size of the database significantly. I found a VMware SQL stored procedure named “dbo.cleanup_events_tasks_proc” that reduced the size of the database by 60%. After a couple of shrink file operations, the database and the vCenter services were up and running. 

However the Veeam backups failed yet again the next night. While the Veeam errors indicated that the vCenter services were again offline, this time it was because the virtual disk containing the SQL Server Express vCenter database was completely full. The transaction log for the vCenter database had bloated to 24GB and filled up the disk. This was confusing initially because I had checked the recovery model of the database prior to running the stored procedure to make sure it was set to “Simple” to prevent this very issue. 

With SQL Server the growth of the transaction log is directly proportional to amount of “work” that SQL Server has to perform between BEGIN TRANSACTION and COMMIT TRANSACTION commands. Certain SQL Server commands (insert, update, and delete) are always wrapped in implicit transactions. But some bulk operation transactions can be executed with explicit BEGIN/END TRANSACTION commands to control roll back. The stored procedure that I ran wraps a potentially large batch purge process in a SQL transaction that enables the entire process to be rolled back in the event of a failure. In this case, the lengthy stored procedure resulted in a ridiculously huge transaction log. Lesson learned is that “Simple” recovery model doesn’t guarantee the transaction logs will always be a manageable size.

After installing a new server and promoting it to a domain controller, the replication from the other domain controller did not work and the NETLOGON and SYSVOL folders were not created. Initially, I tried demoting it and re-promoting it, but that didn't work. I found the following Microsoft Support article - http://support.microsoft.com/en-us/kb/315457 - on how to rebuild the SYSVOL tree and it’s content in a domain. In summary, I had to go into ADSI and delete the orphaned GUIDs and create new symbolic links for both of the folders. I also had to recreate all of the group policies in order for them to work on the new server.

Today the Federal Financial Institutions Examination Council (FFIEC) issued an update to the FFIEC IT Handbook, BCP Booklet.  The update included a new appendix entitled Strengthening the Resilience of Outsourced Technology Services.  The appendix highlights and expands on the BCP Booklet in four specific areas: third-party management, third-party capacity, testing with third-party technology service providers, and cyber resilience.  To learn more, visit https://www.ffiec.gov/press/pr020615.htm  

The sa account for the SQL Instance on a number of PCs got locked out. One way to unlock all sa accounts is by putting the instance in single-user mode and creating a recovery account, then you can get connected to the SQL instance with that recovery account and unlock the sa account.

Here are the instructions for how to do that: [more]

 

1. Open SQL Server Configuration manager and Stop the SQL service. 
2. Once the service stops, right-click the service and select properties. 
   1. Got to the Advanced tab, find the Startup Parameters and add –m; to the front of the line (This will start the SQL Service in Single-User mode the next time it starts up) 
3. Then expand SQL Server Network Configuration, and click on Protocols for your SQL instance. 
   1. Then right-click Named Pipes, go to properties, and change the Pipe Name to just \\.\pipe\sql\query (This will allow you to connect to the SQL instance via sqlcmd) 
4. Then start the SQL Server service again. 
5. Once the service has started open up a Command Prompt on the PC and type sqlcmd. 
   1. At the 1> Prompt, enter CREATE LOGIN recovery WITH PASSWORD = ‘TopSecret1’ and press ENTER (Where TopSecret1 is the password you would like to use for the recovery account) 
   2. At the 2> Prompt, enter Go and press ENTER 
   3. At the next 1> Prompt, enter sp_addsrvrolemember ‘recovery’,’sysadmin’ and press ENTER 
   4. At the 2> Prompt, enter go and press ENTER 
6. After creating the recovery account, go back into SQL Server Configuration Manager, stop the manager and undo the changes you previously made to the Startup Parameters and the Named Pipes configuration. (Remove –m; from Startup Parameters for SQL Server services and change Pipe Name back to what it was originally) 
7. Then login to a PC or Server that has Microsoft SQL Server Management Studio installed and connect to the SQL Instance on that PC with the recovery account you just created. 
8. Once you’re connected to the SQL Instance, go to Security -> Logins, then right-click the sa account and select Properties.  In the Properties screen, click Status on the left.  Then uncheck the box for Login is locked out then click OK. You will get a prompt that the Password needs to be reset, so click General on the left. For Password and Confirm Password enter the password you’d like to use and click OK. 
9. Go back to the SQL Server Configuration Manager on the PC and restart the SQL Server service. 
10. After restarting the services you should now be able to access the DB with the sa account. 
11. After verifying that everything is working correctly, log back into the SQL Instance through SQL Management Studio, but this time use the SA account you unlocked. Go to Security -> Logins and delete the recovery account you created earlier.

 

When setting up a new user using Team Foundation Server, I got an error saying “The path … is already mapped in workspace …” The workspace listed belonged to another user that had previously used the computer. I was able to remove the previous user’s mapping with the command:

tf workspace /delete /collection:"TFSCollectionURL" workspace;owner

Since TFS considers both the computer name and the owner when comparing workspaces, there are a few things to remember:

• If a computer is going to a new user and the computer name has not changed, the workspaces tied to this computer that belong to the previous owner should be removed.
• If a user is getting a new computer and the computer name has changed, the user will need to configure new workspaces on the new computer or update the computer name associated with the workspace before they will be able to access the workspace on the new computer. You can update the computer name for a workspace by running this command on the new computer: 

tf workspaces /updateComputerName:oldComputerName workspacename /collection:"TFSCollectionURL"