Lesson Learned: programs and their directories

At my current workplace, on servers, programs are installed to the Program Files directory on the same disk as the operating system. So far, this hasn’t caused us any problems. In the future, I am now going to insist that there be a separate disk, purely for installing programs onto (example, install Exchange to D:\Program Files).

Why? I’ve gotten into trouble twice now by making assumptions about how particular software packages work. On my Exchange server, I have installed Exchange onto the C: drive alongside Windows. My mailbox databases and transaction logs reside on a separate disk, D:. What I didn’t know, until the C: drive filled up (damn all those space-hogging SxS assemblies!) was that Exchange maintains a transport server queue database in its Program Files folder. Furthermore, OWA utilizes IIS which by default is installed on the C: drive. IIS logs are thus, also stored on the C: drive. The other day, the IIS logs consumed the remainder of the free space and the transport server realized that it was going to run out of space for its queue database. The transport server component therefore shutdown. It should be noted that the transport server queue database can be moved.

However, and the reason this was a really good lesson: not all server plays ball like Exchange and allows you to move these things onto different disks. Case in point: System Center Configuration Manager 2007. When you send a package to a child site, the package is compressed to a file, temporarily, at the root of the disk where Configuration Manager is installed. Again, because I had Configuration Manager installed at C:\Program Files, and my C: disk is 40GB, I quickly ran out of space when I had to send a large package (Adobe Master Collection) to a child site. Configuration Manager, however, does not allow you to specify another location for this compression process. The solution was to either re-install Configuration Manager onto another disk, or resize the C: drive. I did the latter.

I’ll certainly be ensuring that I put applications on a separate, appropriately sized disk (other than the OS disk) in the future.

Windows 7: WScript.Shell Run method from logon script

SYMPTOMNS: When calling the Run method from WScript.Shell object from a WScript-based (VBScript, etc.) logon script deployed via Group Policy, the process runs but is terminated when the logon script finishes processing. When executing the script outside of a Group Policy object, the process runs and is not terminated.

EXAMPLE:

Dim objShell
Set objShell = WScript.CreateObject ("WScript.Shell")
objShell.Run "program.exe"

program.exe will run for the length of the logon script processing and then terminate abruptly.

SOLUTION: set the Run logon scripts synchronously Group Policy setting (under either User or Computer Configuration) to Disabled. Processes spawned via the WScript.Shell Run method will continue to run after logon script processing.

Notes from the Field #2: Catalyst 3750 SW upgrade and ‘does not support the same feature set’

The Catalyst 3750 by default prevents you from changing feature sets (i.e., going from IP Base to IP Services or vice versa) when upgrading the IOS using the archive download-sw command.

Error: The image in the archive which would be used to upgrade
Error: system number 1 does not support the same feature set.

To overcome this, add the /allow-feature-upgrade argument to your archive download-sw command:

archive download-sw /allow-feature-upgrade /overwrite tftp://10.1.15.141/c3750-ipserviceslmk9-tar.122-55.SE4.tar

Notes from the Field #1: ASA

When performing a factory reset (configure factory from global configuration mode), the license key persists and so does enable/console passwords.

It’s also wise to perform a reload after doing a factory reset. Whilst it doesn’t seem required, one of the subinterfaces I had set configured on the ASA to act as a gateway for a subnet was dropping packets, without logging anything.

Exchange 2007/2010 Distribution groups and unauthenticated users

This is going to be a very brief post. I’m currently setting up Nagios to do some network monitoring at my place of work. Several weeks ago, I had upgraded our Exchange 2003 mail server to Exchange 2010. Our e-mail distribution groups were all mail-enabled security groups with global scope. I hadn’t bothered to upgrade them yet to mail-enabled security group with universal scope. I initially had Nagios sending notifications to a particular pre-existing mail-enabled security group that was created when Exchange 2003 was in production. Notifications flowed to members of the distribution group correctly… However, when I changed the contact in Nagios to e-mail a new mail-enabled security group with universal scope, the notifications stopped working. The MTA on the Nagios box, Postfix, was not getting any ‘bounce’ messages from the Exchange server. As far as Postfix was concerned, the message was being delivered. I turned on verbose logging on the hub transport receive connector and verified that the Exchange server was indeed telling the MTA that it had queued the message for delivery. After several minutes of Googling and head scratching I learnt that by default, distribution groups (security or otherwise) don’t accept mail from unauthenticated users. Whilst I thought I had successfully configured the Nagios box to perform TLS authentication, it wasn’t working correctly (the hub transport receive connector log alerted me to this). To resolve this issue, I simply allowed unauthenticated users to deliver mail to the distribution group.

To allow a distribution group to accept mail from unauthenticated users:

1. Open Exchange Management Console.
2. Locate the distribution group in question under Recipient Configuration.
3. Right-click on the group and click Properties.
4. Click on the Mail Flow Settings tab.
5. Select the Mail Delivery Restrictions option and click the Properties button.
6. In the Mail Delivery Restrictions dialog box, uncheck ‘Require that all senders are authenticated’ and click OK on any open dialog boxes to save changes.

Welcome!

Welcome to my blog. My name is Joshua Morgan and I’m currently 20 years old. I currently work in the education industry as a Network Administrator. I run the day-to-day operations of the network, including the servers, virtualization (via Hyper-V), storage, routing, switching, firewalls, etc. Within the next few months I’m hoping to move on and get a job as a Network Engineer, for either a consulting/systems integrator (that would be ideal) or an enterprise…

I’ve created this blog for several reasons. First, I want somewhere I can store my notes of various things I come across or that I’m currently learning (I’m always studying for different IT-related certifications). I also want somewhere I can point potential employers to so that they can see I know what I’m talking about. Hopefully, some other readers will find it interesting or otherwise useful too.

Outside of IT, I’m currently also learning to fly, so you might find some notes on here pertaining to that too.