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:
For years, I have been bouncing between RSSOwl, FeedReader and FeedDemon. I have built the ultimate feed list for the technologies, blogs and news sources I care about. The real beauty of RSS is it enables one to quickly get up to date on news and industry trends without wasting time. New posts are there, you pick the ones that interest you, star or share the ones you care about and ignore the rest. While many of my peers are wasting their time hitting all their favorite sites and going page by page, I have already read it and moved on to real work.
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.
I was asked to get a baseline for generating reports within AD. The two important pieces of information which were required to generate these reports were the ip address and FQDN of each domain controller. The script would then connect to each individual system to gather data. While I was at it, I added the MAC Address just to see what other pieces of data would be useful out of the Win32_NetworkAdapterConfiguration class.
I was recently asked to get a quick report of all Windows 7 computers within a multi-domain AD forest. After banging my head into the keyboard for a while, I finally figured it out. The script below should do the trick.
Also, if you use the OperatingSystemVersion attribute, you will find that Server 2008 R2 shares version “6.1 (7600)". So, the best way to find Windows 7 only, is to search for “Windows 7*” with the wildcard character against the OperatingSystem attribute. That will ensure all Windows 7 versions are returned and will exclude Server 2008 R2 from your results.
In part two, I showed you how to use the Local Security Policy GUI to block the bad guys. There were a lot of pretty pictures for those that prefer the GUI. In this version, I’ll show you how to accomplish the same thing from the command line. This is my preferred method. It is much simpler to automate and explain.
By following the steps below, you will be able to create a new policy and manage the filter lists and actions. The goal here will be to put all these pieces together into a nice tidy package that is fully automated.
In part two, I want to show how you can quickly setup an ipsec policy to block the bad hosts you identified in part one. While many methods can be used to block hosts, using the Local Security Policy (secpol.msc) and ipsec is a simple method which can be fully automated.
By following the steps below, you will be able to create a new policy and manage the filter lists and actions. In part three, I will explain how this can be done from the command line for all you CLI warriors. This tutorial should be accurate for: Windows XP, Vista, 7 and Server 2003, 2008, 2008R2 (possibly even 2000).
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.)