The Days of Our Coronavirus Continue…

  •  
  •  
  •  
  •  
  •  

As you will notice from my post graphic and date stamp today is Thursday, April 2, 2020. Yes, I had to actually take a look at my phone to figure out what day it is! Days seem to be blending into one another as the Coronavirus pandemic continues. A microscopic collection of genetic material has been able to dramatically alter life the way we were accustomed to living. This altered way of life will continue for the forseeable future.

I am fortunate in that the company I work for continues to operate in a remote mode but there are many people I know who have been temporarily laid off of their jobs. The government has started the process of issuing stimulus money for individuals who make under a certain amount of money, sending more dollars to those who have kids. They are also extending the duration of time individuals who have lost their jobs can remain on unemployment insurance and continue to collect money.

On a positive note the nicer weather is starting to arrive here on the east coast. For those who don’t know I live in the suburbs just outside of Philadelphia. This weekend should be in the 60s with sun so I am very excited for that. Yay!

First Post In a Long Time – Coronavirus

  •  
  •  
  •  
  •  
  •  
Message Posted In Philadelphia (March 22, 2020)

This is the first post on this blog in a long time. A lot has changed since my last post and I have been able to see many other parts of the world since that time. This blog entry comes at a time when the Coronavirus (Covid-19) is sweeping through the world at an unbelievable rate. This whole situation is straight out of a movie. A movie that came out in 2011 called Contagion mirrors the current state of the world very well. Most people are stuck at their homes only venturing out to the few stores that are left open. I live in Pennsylvania just outside of Philadelphia which has a number of restrictions currently in place. There are other neighboring counties as well as states across the country who have imposed even stricter rules on businesses and social gatherings. The country and economy are literally on pause at the moment. This pandemic will pass although it shows how quickly the world can seem so small and your life can change so drastically. I will have more to post soon. Until then take care!

Receiving Error – ‘ The security database on the server does not have a computer account for this workstation trust relationship ‘

  •  
  •  
  •  
  •  
  •  
I ran across this issue after having to replace a Windows 2008 R2 System.  I wanted to keep the server name of the new system the same as the old –  (SERVER1) because I wanted to prevent end users from having to delete and re-add any of their network printer resources.  Additionally, many antivirus software clients running on desktops/laptops communicated with this specific server name for their virus definition updates.
I renamed the old server “SERVER1” –TO–> “SERVER5”  and brought the brand new system online as “SERVER1” and joined it into the DOMAIN without issue.  I needed the old server to remain online in the event of a problem.  The system actually ran perfectly fine but a week later I began receiving the trust relationship error shown below when I would try and login to the console with the administrator account.  On one of the network domain controllers I saw the System Event 11 generated as shown below:

Domain Controller Showing System Event 11 Error

 

Windows 2008R2 Error When Attempting to Login With Administrator Account

According to Microsoft – http://support.microsoft.com/kb/321044/en-us

This problem occurs because two or more computer accounts have the same service principal name (SPN) registered. Event ID 11 is logged when the Key Distribution Center (KDC) receives a ticket request, and the related SPN exists more than one time when it is checked on the global catalog (GC) for forestwide verification.  My simple explanation is that the original process of switching SERVER1 to a new temporary name didn’t go right.

The fix was pretty painless.  On the problem server open up a command line and type the following replacing SERVERNAME with the problem system (In this example SERVER1)
note-the first character is an l and not the number 1

ldifde -f c:check_SPN.txt -t 3268 -d “” -l servicePrincipalName –r “(servicePrincipalName=HOST/ServerName*)” -p subtree

Now find the file check_SPN.txt on your drive

The contents of the check_SPN.txt file that is generated should show something similar to the following.  Using the following output information SERVER1 is the system we are having trouble with.  SERVER2 is no longer in service.  As you can see the second portion of the output has a mix of both SERVER1 and SERVER 2 in its output

dn: CN=SERVER1,OU=Servers,DC=YOURDOMAIN,DC=com
changetype: add
servicePrincipalName: WSMAN/SERVER1
servicePrincipalName: WSMAN/SERVER1.YOURDOMAIN.com
servicePrincipalName: TERMSRV/SERVER1
servicePrincipalName: TERMSRV/SERVER1.YOURDOMAIN.com
servicePrincipalName: RestrictedKrbHost/SERVER1
servicePrincipalName: HOST/SERVER1
servicePrincipalName: RestrictedKrbHost/SERVER1.YOURDOMAIN.com
servicePrincipalName: HOST/SERVER1.YOURDOMAIN.com

dn: CN=SERVER2,OU=Servers,DC=YOURDOMAIN,DC=com
changetype: add
servicePrincipalName: HOST/SERVER2
servicePrincipalName: RestrictedKrbHost/SERVER2
servicePrincipalName: TERMSRV/SERVER2
servicePrincipalName: WSMAN/SERVER2
servicePrincipalName: WSMAN/SERVER1.Mcbassoc.com
servicePrincipalName: TERMSRV/SERVER1.Mcbassoc.com
servicePrincipalName: RestrictedKrbHost/SERVER1.Mcbassoc.com
servicePrincipalName: HOST/SERVER1.Mcbassoc.com

Hop into your domain controller and open “Active Directory Users and Computers” and right-click on your domain.  Click “Find” and change the drop down option to “Computers”.  Type the server name that is the equivilent to SERVER2 in the above example and DELETE it.  You should now be able to login to SERVER1 and carry on with your day!

 

GoDaddy Completely Down

  •  
  •  
  •  
  •  
  •  

UPDATE 9/11/2012 5:02PM EST

AnonymousOwn3r has now tweeted and leaked online via isafilehost.com what he/she claims are GoDaddy database/source code information in an attempt to prove their services were breached and not the result of an internal router issue

EDIT 9/11/2012

GoDaddy now states that corrupt router tables were the cause of the outage and not a result of any hack.  Time will tell if this is true as I’m sure those responsible will try again.

As of 2:36pm EST Godaddy and what appears to be most of it’s Internet lying infrastructure especially DNS Resolving system. Email or Web requests to domains registered with Godaddy are bouncing back as non existent/unavailable.  Early word is a rougue member of ANONYMOUS is behind the complete take down of millions of websites