Aug 182011
 

I’ve had mixed results when enabling the “DNSBL” filtering option in Forefront.  When I’ve turned this feature on, I’ve ended up with a number of false positives although it’s been inconsistent in that one minute an address would work and the next it wouldn’t.  The source SMTP server would come up in the NDR as blacklisted but when I checked, it wasn’t.

Rejection Message
mail.iwitl.com #<mail.iwitl.com #5.7.1 smtp; 550 5.7.1 :67.215.65.132:Client host 65.55.111.166 UnknownDNSName; Mail from IP banned. To request removal from this list please forward this message to delist.forefront@messaging.microsoft.com>

After doing some investigating, it appears that part of the DNSBL filtering process is that Forefront does a DNS query for dnsbl.forefront.microsoft.com with the expectation that NXDOMAIN is returned.  Well some providers (i.e. OpenDNS) do the “favor” of replacing NXDOMAIN with an IP for a default search page; when this happens, Forefront blacklists the email.

So a nslookup of “dnsbl.forefront.microsoft.com” using OpenDNS returns 67.21.65.132 whereas a query using Google’s DNS servers returns “non-existent domain”.  The IP address 67.21.65.132 resolves to “hit-nxdomain.opendns.com”.

Changing my DNS forwarders from OpenDNS to Google seems to have resolved the issue.

Aug 152011
 

Exchange 2010 SP1 further exposed the Allow/Block/Quarantine (ABQ) functionality of ActiveSync.  The Exchange Team Blog does a decent job of describing ABQ and the process for managing devices by model.

I recently worked with a client that was looking to take a more restrictive approach to EAS devices and wanted each device approved individually by the helpdesk.  This allowed the helpdesk to see who had attempted to connect a mobile device, send that person the approval form and then approve the device once the paperwork had been received.

Finding information on the necessary delegations proved to be challenging, this is the process I ultimately used:

Create Mail-Enabled Security Group For Quarantine Email Notifications

New-DistributionGroup -Name "Exchange ActiveSync Approvers" -Type "Security" -OrganizationalUnit "iwitl.net/Users_And_Groups/Groups/Security" -SamAccountName "Exchange ActiveSync Approvers" -Alias "EASapprovers"

Enable EAS Quarantine & Configure Notification Email

Set-ActiveSyncOrganizationSettings –DefaultAccessLevel Quarantine –AdminMailRecipients EASapprovers@iwitl.com

Copy Management Role Containing Set-CASMailbox –ActiveSyncAllowedDeviceIDs Command

New-ManagementRole -Parent "Organization Client Access" -Name "ActiveSync Approval"

Remove All Other Commands

Get-ManagementRoleEntry "ActiveSync Approval\*" | Where {$_.Name -NotLike "Set-CASMailbox*"} | Remove-ManagementRoleEntry

Create New Role Group And Nest Security Group

New-RoleGroup -Name "ActiveSync Device Management" -Roles "ActiveSync Approval" -Members "Exchange ActiveSync Approvers" -Description "Members of this management role group have rights to approve and deny ActiveSync devices"

Adding the user to the “ActiveSync Device Management” and “Recipient Management” groups allows a user to approve quarantined devices. The approver will receive an email with a link to the ECP page below; clicking “Allow” and then “Save” will approve the new device.







UPDATE: I recently documented the steps for approving any pre-existing device assocations: Exchange 2010 – Approving Existing Associated Devices When Enabling ActiveSync Quarantine

Aug 112011
 

While working on an OSD deployment with SCCM 2007 R3, I was experiencing some odd driver issues.  Testing a model individually in the lab worked fine but in production, some of the drivers did not appear to load properly from the driver package.  This was a Windows XP image and the mass storage driver in particular wasn’t loading; thus I was greeted with the 0x7B BSOD upon first reboot.

Each model had it’s own driver package created from the driver CABs supplied by Dell.   The task sequence was setup to use a WMI query to apply the appropriate driver package based on the model string in the BIOS.

After reviewing the smsts.log created on the workstation during the OSD process, I noticed the following group of errors:

<![LOG[Copying "C:\_SMSTaskSequence\Packages\P0100036\B7A23FFC-3260-4896-A38D-7A82FCED7867" to "C:\drivers\162".]LOG]!><time="00:33:12.750+240" date="08-06-2011" component="OSDDriverClient" context="" type="1" thread="636" file="driverinstaller.cpp:312">
<![LOG[Adding C:\drivers\162 to plug-and-play search path.]LOG]!><time="00:33:13.733+240" date="08-06-2011" component="OSDDriverClient" context="" type="0" thread="636" file="driverinstaller.cpp:424">
<![LOG[sDevicePath.length() < XP_MAX_DEVICEPATH, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,246)]LOG]!><time="00:33:13.733+240" date="08-06-2011" component="OSDDriverClient" context="" type="0" thread="636" file="sysprepdriverinstaller.cpp:246">
<![LOG[Maximum DevicePath length (4096) exceeded.]LOG]!><time="00:33:13.733+240" date="08-06-2011" component="OSDDriverClient" context="" type="3" thread="636" file="sysprepdriverinstaller.cpp:246">
<![LOG[AddPnPDriverDirsToDevicePath( sTargetPath ), HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,714)]LOG]!><time="00:33:13.733+240" date="08-06-2011" component="OSDDriverClient" context="" type="0" thread="636" file="sysprepdriverinstaller.cpp:714">
<![LOG[Failed to update device path in offline registry. Code 0x80004005]LOG]!><time="00:33:13.733+240" date="08-06-2011" component="OSDDriverClient" context="" type="3" thread="636" file="sysprepdriverinstaller.cpp:714">

Reviewing the driver packages, I found that the source directory UNC was pointing to the same root directory for each package.  So while looking at the driver list in the SCCM console only showed the drivers for that particular model, the package actually contained the drivers for all of the models.  As a result, during the OSD process, SCCM was pushing down the entire driver database.

After some research, I found that the Windows XP driver path in sysprep.inf has a limitation of 4,096 characters (KB31235) and the large number of drivers in the entire database appeared to have been exceeding this limitation.

Correcting the source directory path for the driver packages reduced each package size and also corrected the OSD deployment issues.

Aug 112011
 

The “Hello World” of blog posts.

My goal is to keep a steady pace of posts with sufficient detail to be of help others.  Given that this has been something I’ve intended on doing for over a year, I should have a decent amount of content stored up to at least cover the first few weeks.  The blog format is pretty basic right now while I become familiar with WordPress and focus on content.

Expect the topics covered to include just about anything from the Microsoft catalog, VMware and any other technology I may run across.