Blog: Networking

Microsoft has changed the query syntax for creating Exchange Address Lists and Email Address Policies in Exchange 2007. In Exchange 2003, all recipient filters were created with LDAP queries. In Exchange 2007, a new filter syntax called OPATH has been introduced. OPATH is easier to write and makes queries easier to understand, but any ALs or EAPs that are carried over as part of a migration from Exchange 2k/2k3 to 2k7 must be updated to use OPATH instead of LDAP. Here is an example of such a conversion:

LDAP: 
(&(&(&(&(mailnickname=*)(|(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))))))
(objectCategory=user)(physicalDeliveryOfficeName=morton*)))

OPATH:
( ( ( Alias -ne $null ) -and ( ( ObjectCategory -like 'person' ) -and ( ObjectClass -eq 'user' ) -and ( recipientType -eq 'UserMailbox' ) ) ) -and ( ObjectCategory -like 'user' ) -and ( Office -like 'morton*' ) )

To save a lot of time by avoiding doing these conversions by hand you can use the LDAP to OPATH filter conversion script script provided by the Microsoft Exchange Team.


 

We were trying to update Symantec Mail Security (SMS) for SMTP from v4.0 to v4.1 and the upgrade routine seemed to hang during the ‘Java Liveupdate’ portion.  Server hard-drive activity was heavy at that point and Task Mgr showed the upgrade ‘running’, but we did not seem to be making progress.  We installed a Java-runtime update and found a Symantec Java-liveupdate hotfix, but we ran out of time and had to leave the server @ v4.0  We went back on site Monday ready to uninstall Java Liveupdate, but the add/remove routine behaved similarly – heavy drive paging and the routine showed running, but no progress was occurring (waited 15 minutes).  I found a symantec procedure to manually remove Java Liveupdate and was going thru that, deleting folders, when I came upon ‘C:\Documents and Settings\All Users\Application Data\Symantec\Java Liveupdate’  Before deleting it, I looked inside – it had 1 folder called ‘downloads’, which contained approx 21,000 pattern update folders going back to 2004.  I deleted all these subfolders, which took about 25 minutes.  After that completed, I re-ran the v4.1 upgrade, which ran thru with no problems.  Whether it was the upgrade routine or Jave Liveupdate uninstall, the server was obviously trying to process all these subfolders and choking on them (might have eventually completed if given long enough).  So, when working with Java Liveupdate, it is probably a good idea to look for this downloads folder first and clear it out.


 

A task to have standard Outlook signatures started me on a Google search.  I found solutions for setting up the signature on each user’s computer for small companies as well as some applications for sale that would allow you to tweak Outlook for larger companies.  What I ended up doing was taking a snapshot of a VM machine before and after I applied the signature.  I then used WinInstall LE to find what changes occurred to the system between the before and after snapshot.  The actual signature is saved in three formats (html, rich text, and plain text) in %UserProfile%\Application Data\Microsoft\Signatures.  A personal profile configuration file (*.pip) is also changed in Outlook called MSOut11.pip.  This file is located at %UserProfile%\Application Data\Microsoft\Office.  By modifying the three signature files for each user, and adding these files to the user’s profile, you can create a standard signature for anyone in a company. 

Disclaimer: This currently has only been tested in a terminal server environment running Windows Server 2003 and Microsoft Office 2003.


 

When restoring a Microsoft Exchange 2003 database, be sure an actual database file exists to restore to.  A restoration of the Exchange Information Store is not a file restore, so the files already need to be in place.  Beginning from scratch in a disaster recovery scenario, you will need to:

  • Install Exchange (since the Exchange installation directories should not be included as part of the file system restore)
  • Patch Exchange with the same Service Packs and Patches that were previously installed
  • Mount the Information Store (empty at the time) – this will create the necessary empty databases
  • Dismount the Information Store (and set it to be able to overwritten by a restore procedure)
  • Run the recovery of the information store
If all goes well, your Exchange installation should be back and running.

 

The default local security policy on Windows Vista is set to use NTLM v2 only.  After some off and on troubleshooting I finally discovered this was preventing me from accessing my Western Digital NetCenter NAS.  The following procedure changes the policy to allow older Lan Manager Protocols if needed: [more]

  • Run MMC snap-in secpol.msc
  • Expand Local Policies -> Security Options
  • Find Network security: LAN Manager authentication level
  • Double click and change to “Send LM and NTLM – use NTLMv2 session security if negotiated”

 

  1. Basic disks use the original MS-DOS-style master boot record (MBR) partition tables to store primary and logical disk partitioning information. Dynamic disks use a private region of the disk to maintain a Logical Disk Manager (LDM) database. The LDM database contains volume types, offsets, memberships, and drive letters of each volume. The LDM database is also replicated, so each dynamic disk knows about every other dynamic disk configuration. Performing FIXBOOT and FIXMBR in the recovery console of a system configured with Dynamic disks has no affect on the health of the LDM.
  2. Never break a healthy system disk or boot dynamic mirrored volume and expect the mirrored drive to replace the original primary drive if it fails. The manually broken mirrored drive is assigned the next available drive letter, and this is updated to the permanent record in the LDM database. This means that regardless of what position that drive takes in the boot process, it is assigned the new (and incorrect) drive letter, so the operating system cannot function correctly.
  3. If you want to replace a failed disk in a dynamic disk-based volume, shut the system down just like normal. Do not break the mirror or change the volume properties in preparation for the removal. Once the system is down, replace the bad drive and reboot. It may be necessary to place the secondary drive at the same SCSI ID as the primary before reboot if you are replacing the primary drive in a mirrored set.

MANY other helpful hints are available at http://support.microsoft.com/kb/816307.


 

When making registry changes, it is a good practice to export the key first.  But many times, we are adding new items and not just modifying values on existing items.  So if you import from the file you exported to, it does not remove the new items that were added.  To do that, add a line at the top of the registry file with a minus in front of the key, like this, for example:

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]

This will cause this key, all it's subkeys, and items to be removed first, then the rest of the information will be added back.  If the key does not exist, then no error occurs.  This is probably a good practice to follow when putting together a .REG file to deploy so that nothing else will be under that key.


 

While working on a task to upgrade the hard drives on a Windows 2002 SBS machine. I installed Acronis in order to create an image of the C & D drive then recover it to the new larger hard drive. I recovered the image to the new drives and finished getting everything back online.

I decided to uninstall Acronis which showed to uninstall just fine using it’s uninstall. After backup ran that night it had Volume Shadow Copy errors. I checked and found that the Microsoft VSS writers where not accessible. I ran “VSSadmin / list writers” which showed there was no writers available. After researching I found that others who uninstalled Acronis 9.1 had the same issue. I could not find a solution that worked for anyone. I found an article (linked to below) that has a list of DLL’s that Micrisoft Premier Support recommends to reregister. I reregistered the DLL's and after a reboot there were still no VSS writers available.  [more]

I then decided to run System File Checker which is built into Windows XP and Server 2003. I used “sfc.exe /scannow” and let it run. After which I reregistered the DLL’s like before. This time when I ran “VSSadmin /list writers” all the writers were listed. I went back to Backup Exec and was able to select “Shadow?Copy?Components” and “System State”, which I could not before.

Link to information about SFC.exe   -   http://support.microsoft.com/kb/310747
Link to list of DLL’s to reregister  -   http://backupassist.com/phpBB3/viewtopic.php?t=28


 

I was working on a server that was running low on disk space on the system (C:) partition.  I was able to free up some space rather quickly (by removing the Automatic Update downloads), but when I checked the Event Logs, the Application log was filling up with errors from SMS for Exchange.  The message was that the virus definitions were corrupted.  It appeared that the XDB down script had run around lunch time and updated the virus definitions, but wasn’t able to complete the install due to low disk space.  Despite the partial install, SMS for Exchange appeared to be trying to use the corrupted definitions.  When I tried to run LiveUpdate (as recommended by the Event Log message), LiveUpdate said everything was current.  People were starting to have problems with their e-mail (and for some reason the server was beeping irregularly on site).  I stopped the SMS for Exchange service (which fixed the e-mail and the beep), but the service wouldn’t restart.  I tried restarting the main Antivirus service as well, and it would not restart (also because of corrupt virus definitions).  I had to manually stop all the Symantec services, remove the partially installed virus definitions from the C:\Program Files\Common Files\Symantec Shared\VirusDefs folder, manually edit the USAGE.dat file (which tells the Symantec products which defs to use), then restart the services.  Once the services were up and running on the previous virus defs, I was  able to re-run the XDB down script and let it update the defs to the most current.


 

When running dcdiag.exe from the Windows Support Tools against a x64 domain controller, make sure you are running the x64 version of dcdiag.exe. If you try to run the x86 version of dcdiag remotely against an x64 domain controller, the tool may report errors when there really isn’t anything wrong. In my case, I could not get the x64 domain controller to pass the Kerberos and DNS tests when running dcdiag.exe against it from a remote x86 server; however, when I installed the x64 version of the support tools locally on the domain controller, everything passed without error.