On your SBS 2011 server, do you find a lot of DCOM errors in your System Event Log? These are relatively common on SBS boxes. Microsoft’s guidance is that these can be safely ignored. However, when an error is reported, I expect it to be something that should be investigated. If it can be ignored, it shouldn’t be reporting it as an error. Fortunately, there is a fix for these.
The IT ecosystem is rich with network monitoring systems (NMS). Each NMS has different capabilities, costs, and purposes in life. It is commonplace for me to come into a business that has invested in an NMS that doesn’t fit all their needs. You might ask, “What does this have to do with creating a Windows service?” Here is the scenario that brought this up.
A client has a monitoring solution for their Windows servers and some basic network up/down stats. Their internet connection had been flaky for a month or two. As we worked with their ISP, their connection continued to stay up but latency would spike and often drop packets. The monitoring never sees the link as down but the level of service is degraded and mostly unusable. The ISP can quickly reset the ports and fix the issue, but we want to know right when this happens to minimize downtime.
I came across an undocumented app the other day. For a number of reasons, we needed to restore the password but it wasn’t documented anywhere. Luckily, the service account was setup in an app pool. In IIS 7.0 or 7.5, APPCMD can be used to recover the password. In 6.0, adsutil.vbs can be used.
cscript.exe /nologo adsutil.vbs GET W3SVC/AppPools/AppPoolName/WAMUserPass However, I wanted to write my own little script. Having a little tidbit makes it easy to reuse later for other clients. For example, I could search AD for SPNs starting with “HTTP”, loop through each of their app pools and document the username and passwords for all service accounts used in this fashion. So, here is the little tidbit I threw together.
Here I go on another vbScript tutorial. You might ask why I’m not doing this in powershell yet and it is simple: I still run into 2003 and XP environments. Oh yeah, and this works. I don’t care what scripting language I’m writing in if it gets the job done; you shouldn’t either. My $0.02. If you want to download this script, click here: Morto.A Detection Script.
A had to do a little cleanup on a network from the Morto.A worm. The first thing I wanted to do was find out how bad things were. They were reporting a DDOS across their LAN (mostly 3389) and a lot of other issues. It as obvious we were going to need to rebuild a few systems but we wanted to get a grasp out of what the damage was. This were generally working: logons, shares, etc.
Whenever I am doing large sweeps of the network that require connecting to a large number of workstations (e.g. file copy, wmi query, etc.), I prefer to check to see if I can even see the system. This avoids waiting for (WMI) timeouts and also aids in troubleshooting failures. If the file copy failed, why? Well, if I can’t ping it or it can’t be resolved, I would like to know right away and move on to the next host.
In a recent incident, an Exchange server had a complete volume failure during testing. Exchange 2010 was reinstalled but when installing Service Pack 1, it failed upgrading the Mailbox Role. Upon reviewing the log, I found the following line:
Database is mandatory on UserMailbox. Property Name: Database The error doesn’t explain the problem very well but it is basically saying that there is a UserMailbox without a database, which should never happen. The failure of the volume and subsequent reinstall of 2010 left the arbitration mailboxes (and one or two user mailboxes) orphaned. Most of the suggestions to resolve this problem list doing things like deleting the system mailboxes and running “setup.com /PrepareAD”. After looking around, I was able to parse together a few other options and find a fix.
Twice in the past two weeks, I have come across Exchange 2003 to Exchange 2007 migrations which went uncompleted. In both cases, I received the following error(s) when trying to view the properties of a recipient with spaces in its alias or when viewing the properties of the offline address book:
The properties on have invalid data. If you click OK, default values will be used instead and will be saved if you do not change them before hitting Apply or OK on the property page. If you click cancel, the object will be displayed read-only and corrupted values will be retained. The following values have invalid data: Alias. WARNING: Object has been corrupted and it is in an inconsistent state. The following validation errors have been encountered: WARNING: is not valid for Alias. Set- : is not valid for Alias. Exchange 2003 would allow an administrator to put spaces in the Alias attribute. That poses a problem for 2007 which is strict about the characters it allows in this attribute. In Exchange 2007 the following characters are considered valid: Strings formed with characters from a to z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. But, no spaces.
Yes, I still use vbscript. Someday, I’ll get to work in an environment where everything is upgraded. Until then, I have to rely on the tried and true vbscript.
One of the most common uses of a Group Policy startup script is for adding users to the local admin group. Just google it and you will find hundreds of scripts doing just that, batch files, posh, vbscript, perl, etc. I wrote the script below because I wanted the flexibility to reuse this script at any client and for any group (not just Administrators but Remote Desktop Users or Power Users).
Most people have a fear of taking their vehicle to the mechanic for even the simplest tasks just to find out they need their transfunctioner adjusted because of wear to the driver’s side steering widget. For many in the SMB market, that same fear can be found in their technology investments. “Did that last IT guy wrap our SQL server in duct tape and tie it to the web server with shoe string?” The reality is often not that bad, but it can be unsettling not knowing.
On Friday (May 6th), Microsoft released the Enterprise Beta Readiness Tool for Office365. As the name implies, this tool is meant to do a quick readiness check on your environment. Upon execution, it will automatically extract the files to C:\office365reskit and launch the app within IE. If you system has IE locked down, this may be problematic or at least require the acknowledgement of a few warnings. As it’s running, it collects information (be patient) from your organization’s network into its temp directory (C:\office365reskittmp). The files within this directory are plain text and offer an interesting look into the environment. Unfortunately, once the test completes, the utility analyzes and consolidates these temp files and deletes the originating files, leaving a technical person with much to be desired.