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.
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).
As is often the case in IT, when you need to push out that software package or migrate that computer to a new domain, it isn’t on the network. This has come up several times in the past year and I wanted to share my solution. Now, this isn’t the “greenest” solution because this will ensure your clients never go into a power saving mode. However, it can be a temporary fix for a project. It can also be adapted to force standby or hibernate at specific thresholds.
Back in 2007, the Microsoft Scripting Guys posted a article titled “Hey, Scripting Guy! Be Careful What You Say.” This article changed everything in the way I scripted because it should how simply you can access some .Net classes through COM callable wrappers. The two they focus on are “System.Random” and “System.Collections.ArrayList”.
Set objRandom = CreateObject("System.Random") Set objArrList = CreateObject("System.Collections.ArrayList") ArrayList # When scripting in AD, Exchange or even the desktop, I am consistently working with arrays. Adding items and sorting arrays always required custom functions, overly wordy statements or re-dimensioning. This made working with arrays cumbersome. Their example for sorting the non-.net way:
I’ve been using a routine to determine 64-bit v 32-bit workstations for some time checking the registry for the PROCESSOR\_ARCHITECTURE in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment path. However, this was proving to be error prone. So, I just gave up that method altogether since all Windows x64 editions have a “%SystemDrive%Program Files (x86)” directory. This makes it just a quick and easy call the folderexists method of the filesystemobject.
The only downside is that can’t be used remotely but since most of my scripts are used in local policies, this shouldn’t be an issue.
Due to some software requirements, there was a need to get JRE 1.5.0_09 rolled out across our enterprise. The requirements were pretty straight forward:
Only install on client operating systems (Windows 2000, Windows XP, Windows Vista and Windows 7) Detect the versions of Java installed. If 1.5.0_09 is installed, exit. If 1.5.0_08 or less was installed, install this version. If it has a newer version, do nothing. The best way of determining the Java versions is to look in %program files%. On 64-bit machines, this is “C:program files (x86)Java”. On 32-bit, this is “C:program filesJava”. The script accounts for this.
While troubleshooting some issues on an OWA Front-End server, I went over to the security log to see if the authentication attempts were getting past this box. The problem I found was the log was so full of failed logon attempts it was difficult to filter out what I was looking for. In a twelve hour period, there were thousands of 529 events in the security log. Now, I know this is nothing new, but I found a few patterns. I manually exported the log to a CSV, parsed out all the source ip addresses and opened it up in Excel. What I found was that 98.7% of failed logon attempts were made by just four different ip addresses. (I recommend using MaxMind’s GeoIP Address Locator for help in determining where the source addresses are located.)
So, my buddy (and former co-worker) called me yesterday for some help with a script he put together. His script checked the local profile in Outlook for any PST files that were stored locally. If it found any, it would them move them to the users home space. We tried and tried to get the script to work properly but it never seemed to work 100%. Being that he is a good friend and this would be useful at work, I decided to take the work he had put in and get the thing working.