Wednesday, December 12, 2007

Script to Audit Service Accounts

Although it is not a good practice to use domain Administrator as a service account, it is still very likely to find such implementations in many organizations. In addition, even if administrator is not used, the same service account can be in use on multiple servers and for multiple services. If there's no document or database available in your environment to keep track of these service accounts, you are in trouble. And if for some reason you need to change the password of these service accounts, you have to know which servers and which services will be affected with the password change.

The script addresses this need. It scans the given list of servers and tries to find a match for the provided keyword in the service accounts. Any matching service and computer name is logged and displayed on the screen. You can use the output file as a reference for updating the passwords. Script does not provide any password change functionality.

Usage:

cscript q_svc.vbs filename keyword

For example:

cscript q_svc.vbs serverlist.txt mydomain\adm

or

cscript q_svc.vbs serverlist.txt svcadmin@mydomain.local


Since the script uses string functions, for example, "mydomain\adm" search will catch both "mydomain\admin" and "mydomain\administrator" accounts if they exist.

You have to be careful and remember that service accounts sometimes are stored in UPN (username@domain) format. If you do a search for "mydomain\adm" only, you will miss the entries like administrator@mydomain.local. On the other hand, a search with the keyword "admin" will catch both type of entries.

To download the script and sample serverlist.txt file, click on "I agree", you will be forwarded to the download site. Modify and populate the serverlist.txt file with your server names, decide on the keyword to search for, then start the script. Test it and if you have any ideas or questions regarding this script, feel free to contact me using the comment link.

Update to the Post:
Somehow, the old free file hosting company decided that these utility scripts cause "abuse/copyright violations" and decided to remove them. Instead of trying to convince them that these scripts belong to me and has nothing to do with abuse, I simply moved them over to another (and better) file hosting service. Sorry for the inconvenience, and thanks for warning me about the dead links.
Another Update to the Post:
Thanks to Mark Vaughn, I realized that the script was not working as intended. I had to change the search logic a little bit. Instead of using queries with "like" on Windows 2003 systems, it checks each service for the given keyword now. I apologize for any inconvenience I might have caused with the previous version.
 

Thursday, November 29, 2007

Wednesday, November 21, 2007

Interesting Behavior in Backup Exec 11d

If you have a combination of Microsoft Exchange Server and Symantec Backup Exec in your environment, you are probably aware of the new (approximately one year old) feature in Backup Exec 11d which eliminates the need for a seperate Mailbox-Level (or Brick Level) backups. With 11d, you can perform mail-level restores from your Information Store level backups. Very neat, isn't it? Well, if you can configure it properly, yes.

According to administrator's guide and web documentation, all you need is a dedicated mailbox for the Backup Exec Service Account if you are using tape devices as backup targets.
When you define your backup job, you should also select the "Enable the restore of individual mail messages and folders from Information Store backups" check box intuitively.

Interestingly, this configuration only seems to work for Exchange 2007. If you have Exchange 2003 in your environment and try to perform mail message restores from the Information Store backups, you will notice that you cannot even browse the list of mailboxes in the Restore Wizard screen. Solution to this problem lies in the general options screen. Go to Tools menu, select Options, then select Exchange under Job Defaults. You will see "Enable the restore of individual mail messages and folders from Information Store backups" option already selected. Additionally, don't be fooled by the misleading "not recommended" section, and select "Enable legacy mailbox support (not recommended - use information store instead)" check box.














Remember, you still do not want to do mailbox level backups. After the legacy mailbox support is enabled, test these new settings with a new Exchange Information Store backup. You will see that the individual mailboxes can be browsed and individual messages can be restored after these changes. As a final reminder, I have to add that this information applies to Backup Exec 11d Build 7170. Maybe Symantec will decide to change at least the "not recommended" section in the following releases, who knows?

Update:
My recent experiences with Backup Exec showed me that this behavior is not consistent among all Exchange 2003 and Backup Exec 11d deployments. So far I haven't been able to define the exact conditions to reproduce the problem. I have done two implementations with Exchange 2003 and Backup Exec 11d which required the settings above for mail level restores, and done one recent implementation which did not require any modifications and worked as described in the Admin Guide. I will try to update this post if I can find more information on this topic.

Wednesday, October 31, 2007

Script to Update Computer Description

A while ago, a colleague asked me if there was a way to centrally update the "Description" fields of workstations with their users' names. The desktop support team was remotely managing a couple of different organizations, and some of them had no method or documentation for matching the user names and the computer names. Although as an alternative approach, Bginfo from sysinternals (now part of Microsoft - http://www.microsoft.com/technet/sysinternals/utilities/bginfo.mspx) could be used to display the information on each desktop, the other way for desktop technicians was to look at the description of the computer from the network browser.

As a solution, I wrote a script. I started with a vbscript file, then ported it to HTA to make it reusable. It basically checks the current logged-on user, determines the user's logon name and display name from AD and updates the computer description field either with the logon name or with the display name.

It requires read rights from AD and local administrator rights on the workstations. It only updates if the "Description" is empty. It does not do any changes if no logged-on user can be detected on the workstation. It lets the admin to choose from Display Name or samAccountname attributes of the user to update the Computer Description field.

Please remember that this script is written for and tested on Windows XP systems. If workstations are protected by windows firewall, file sharing exception should be enabled.
Even before attempting to use the script, make sure you read and understand the disclaimer section in the right column. Do not even think of using this script in your production environment before testing and approving in a lab.

If you're ready for download and agree with the disclaimer terms, click on "I Agree" to reach the download page. Copy this file to your test environment and start testing. It requires an input file which lists of computer names, and of course your AD (test) domain name. Test it and if you have any ideas or questions, feel free to contact me using the comment link.

I hope you find this script useful. I will try to post similar scripts for various tasks.

Update to the post:
Somehow, the old free file hosting company decided that these utility scripts cause "abuse/copyright violations" and decided to remove them. Instead of trying to convince them that these scripts belong to me and has nothing to do with abuse, I simply moved them over to another (and better) file hosting service. Sorry for the inconvenience, and thanks for warning me about the dead links.

Thursday, October 25, 2007

First post

I have been planning on creating a blog and sharing my experiences with the IT community for a while - for almost two years actually. Finally, I found the time and the will to create this blog.

Although I will try to include some details about myself in the "profile" section, here's some brief information about me: I have been working in the IT market for fifteen years. I have always worked in technical positions and mostly with Microsoft Server technologies. I have collected (and still collecting) a considerable amount of experience with Windows Server, Active Directory, Exchange Server, Desktop Management. I am also a great fan of scripting technologies like vbscript, batch files (yes, why not?) and powershell. For the last couple of years I have produced a number of vbscript files for automating different tasks.

In this site, I will try to share my sample scripts as well as some tips and tricks on Microsoft technologies. Check back often to see the new entries, and I hope you'll find some useful information here. Please do not hesitate to send your comments and questions.