Exchange 2007 orphaned Delegate User causing Bouncebacks
Having recently deleted an Exchange 2007 User from AD we found a number of bounce back emails beginning to occur. The bounce backs would occur primarily on editing Calender items for other users as the now deleted user was still listed as a Delegate for them. We wanted to query Exchange as to which mailboxes the now deleted user was listed on. The bounce back email is below:
Delivery has failed to these recipients or distribution lists:
Username
The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.
FIX:
1. Open Exchange 2007 PowerShell
2. Run the below query replacing $User with the name of the deleted user (e.g John Smith). This will output the details into a text file (C:\delegates.txt).
-
get-mailboxcalendarsettings | where-object{$_.ResourceDelegates -match"$user"} | out-file c:\delegates.txt -enc ASCII
Exchange 2007 4.3.1 Insufficient System Resources
We recently had a server that was receiving mail correctly, although the emails themselves were then never reaching the internal recipients. Checking over the Event Logs we saw the below error:
Level: Error
Source: MSExchangeTransport
Event ID: 15006
Reading on this further it looks to be due to a feature of the Exchange Transport service that monitors system resources called Back Pressure. We were running a little low on disk space so the easiest fix for us was to move the Queue to a different drive, the below sites explain this in full detail so are worth a read if you experience similar.
Microsoft Technet - Understanding Back Pressure
MSExchange.org - Understanding Back Pressure Feature in Exchange 2007
Petri.co.il - Back Pressure: Moving the queue Database in Exchange 2007
Server 2008 R2 Network Shares with WD TV Live
Having been so impressed with the WD TV I picked up the WD TV Live to stream my various media over my home network.
At current my media is shared from a Windows 2008 R2 Domain Controller, which from various forum posts seems to be causing problems for the WD TV in browsing shares. Playing with a few settings it now seems to be working perfectly so thought I'd share my findings.
Setup:
Windows Server 2008 R2 as a Domain Controller
Firewall Disabled
Shared Media drives/folders with Everyone given Read Access
User Account created specifically for shares, set with default Domain User membership
WD TV Live device on DHCP
With the above configured the device would see the server and using domain\user credentials it would attempt to connect. This appeared successful however it would then show that it could not see any shares / no media detected on the server. Playing with this further it looks like the below has resolved the issue (at least in my case).
Firstly I needed to amend the servers local Group Policy to allow Link-Layer Topology Discovery (a work colleague had mentioned this step being posted on some of the AV/WD forums).
To do this click Start - Run - type in gpedit.msc and click OK.
Browse to Computer Configuration - Administrative Templates - Network - Link-Layer Topology Discovery.
In here set both items to Enabled as per the screenshot.
Once set open at Command Prompt window to run gpupdate /force
Next I checked the services running and noticed the SSDP and UPnP services were set to disabled. I set these to Automatic and then started them both.
I tried to connect again although got the same error. Checking wire shark it didn't seem to be sending the domain\user credential correctly as it removed the \ and combined the domain with the username. Connecting again with just the Active Directory user account with no domain set it has connected and I can successfully browse shares. I've also set the device with a DHCP reservation as I've read a few places that mention the device disconnecting every so often when streaming media.
So far all seems fine, have watched a few films, turned the device off / on etc and it works a treat!
**NB Since using this more I've noticed when turning on my Win7 laptops that it kills the WD causing it to drop the network shares. It looks to be due to the Streaming options that Win7 has introduced, so the quick fix is to disable sharing on these devices and you should find the WD TV Live plays again uninterrupted. I'm looking to confirm the exact sharing options that cause this shortly.
Blank resource list in Symantec Backup Exec 12.5
After installing Symantec Backup Exec 12.5 and setting the services to run under a newly created Active Directory account, we found that when trying to create a backup selection list the resources box was blank. The following error was seen:
Connection with server Failed. Hit <F5> to refresh.
This was due to the service account missing appropriate permissions. After running through this Symantec article to ensure all the requirements were on the account, we also needed to amend a Group Policy allowing the service account "Log on as Batch Job" rights.
To do this check the below:
- Load up Group Policy Management (Start - Run - gpmc.msc)
- Edit the Default Domain Controllers Policy
- Browse to Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Users Rights Assignments
- Edit the "Log on as a Batch Job" policy
- Add the appropriate Service Account
IIS7 HTTP Error 500.19 – Internal Server Error
Having upgraded a Server 2008 box with Service Pack 2 we noticed an issue when creating/using custom error pages in IIS. Unless it was down to my poor search terms I couldn't initially find much on the error as I'm no IIS expert, but it appears to be down to some changes made to IIS as part of the SP2 upgrade.
As the server was hosting Microsoft Exchange 2007 it was used for Outlook Web Access. We tend to make use of the redirect page to load from mail.domain.com straight to https://mail.domain.com/owa as per this MS article
When setting this up we found we received the below error (as well as Outlooks Out of Office not working):
ERROR:
HTTP Error 500.19 - Internal Server Error
Absolute physical path "C:\inetput\wwwroot\redir.htm" is not allowed in system.webserver/httpErrors section in web.config file. Use relative path instead.
FIX:
To resolve this as the error states we just needed to amend the path to the custom error page. This can be done either in the IIS console or by editing the web.config file usually in the \inetpub\wwwroot folder. Open the file in a text editor and edit the file path.
Absolute path:
-
<httperrors>
-
<remove statusCode="403" subStatusCode="-1" />
-
<error statusCode="403" prefixLanguageFilePath="" path="C:\inetpub\wwwroot\redir.htm" responseMode="File" />
-
</httperrors>
Relative path:
-
<httperrors>
-
<remove statusCode="403" subStatusCode="-1" />
-
<error statusCode="403" prefixLanguageFilePath="" path="redir.htm" responseMode="File" />
-
</httperrors>
Exchange 2007 Update Rollup 9 breaks OWA
Having installed Update Rollup 9 for Exchange 2007 on a number of different sites we finally had one that broke Outlook Web Access. OWA would load yet several images were just placeholders and after logging in no actual inbox could be read as all the Fonts and styling were screwed up.
Checking this site may help - Click Here
In our case running the UpdateOWA.ps1 resolved the issue.
FIX:
Step 1) Load the Exchange Management Shell
Step 2) Navigate to your Exchange Bin directory via the management shell - usually C:\Program Files\Microsoft\Exchange Server\Bin
Step 3) Run the UpdateOWA.ps1 script (done by entering .\UpdateOWA.ps1)
Outlook Web Access IIS Redirecting HTTP to HTTPS
One thing I still find with users is that they love to mistype URLs! One common mistake is to enter in the Outlook Web Access URL without specifying the https:// prefix, so here's how we can have http:// automatically redirect to https:// for the OWA directory
Note: this is based on a Small Business Server 2008 install although can apply to any standard Exchange 2007 setup
Step 1) Open up the IIS Console and expand the appropriate Site containing the OWA folder. Select the OWA folder.
Step 2) Open up the Error Pages icon.
You should now see a list of the default error pages
Step 3) On the right side of the window under Actions click Add
Step 4) Create the following custom error page and click Ok
Status Code: 403.4
Select Respond with a 302 redirect
Enter the full HTTPS URL to your OWA location e.g. https://mail.mydomain.com/owa
Step 5) Test the redirect is now working from a client machine
Moving Public Folder Replica – SSL Certificate Error
As part of a recent SBS 2003 - SBS 2008 migration we came across the following error when trying to move the Public Folder's from Exchange 2003 to Exchange 2007. When we told Exchange 2003 to move the Replica Set we saw the below error:
The SSL certificate server name is incorrect
ID no: c103b404
Exchange System Manager
Searching for a resolution we found a number of sites that listed removing the SSL certificate requirement on the exadmin folder (As per http://support.microsoft.com/kb/324345). Unfortunately this wasn't a complete fix as it also appeared we then needed to use adsiedit to remove the :443: binding on the service. The fix below worked for us:
- In IIS navigate to the Exadmin folder, Right click to bring the “Properties” window up and go to the “Directory Security” tab
- In the “Secure Communications” section select “Edit”.
- Make sure to deselect “Require secure channel (SSL)” and “Require 128-bit encryption.”
- If the “Require 128-bit encryption.” is selected and greyed out, make sure to select “Require secure channel (SSL)” and deselect “Require 128-bit encryption.” then deselect “Require secure channel (SSL)” again.
- Goto Start – Run and type adsiedit.msc
- In the left side pane expand the Configuration container.
- Next expand CN=Configuration, then CN=Services, CN=Microsoft Exchange, CN=, CN=Administrative Groups, CN=First Administrative Group, CN=Servers, CN=Protocols, CN=HTTP, CN=1
- Right Click on CN=Exadmin and choose Properties.
- In the Properties dialog box you will see 2 drop-down lists. drop down the top list and select “Both”. Drop down the second list and scroll down to the attribute “msExchSecureBindings” and double click on it.
- If this attribute is set to 443, click the 443 value to select it and click the “Remove” button. Then click “Apply” and then “OK”
- Close out of ADSI Edit,
- Restarted IISadmin service
Test the replication again, hopefully all should now be working as expected.
McAfee 8.7i On Access Scan Disabled after install
Having set up a new PC and installed McAfee VirusScan Enterprise 8.7i (with or without Patch 1) every so often on different setups we find that it fails to start and reports the On Access Scan / Buffer Protection and Access Protection components are disabled. This failure to start is after rebooting the PC once the application has been installed.
If you check the McAfee services all are started except the McAfee McShield service which although is on Automatic fails to start.
Then checking Event Log we see the following error on the Vista PC's:
Log Name: Application
Source: McLogEvent
Event ID: 5004
Could not Contact Filter Drive. Error = 0x7d1 : The specified driver is invalid.
FIX:
To fix the above we found making the below changes to some registry keys did the trick.
1) Open Regedit
2) Navigate to HKLM\SYSTEM\CurrentControlSet\Services\
3) Find the ImagePath key for mfeapfk, mfeavfk and mfebopk
4) Edit the ImagePath to reflect the full path to the .sys file - this is usually just a case of adding c:\windows\ in front of the path.
5) Make this change for the 3 listed McAfee keys (mfeapfk/mfeavfk/mfebopk)
6) Start the McAfee McShield service
Login Failure Error Accessing Server Shares
Recently working on a File/Print server (that was also a backup DC) and began to receieve the following error from client PC's trying to access it -
Login Failure: the target account name is incorrect
Most google posts seem to refer to checking DNS/WINS settings although in this case everything was fine. I could access the shares via \\192.168.xx.xx but not \\servername. Looking in to the error further there were some error logs referencing kerberos issues and the main clue was found after running netdiag. The netdiag report came back with the below error -
[FATAL] Secure channel to domain 'MYDOMAIN' is broken. [ERROR_ACCESS_DENIED]
So if your having a similar issue then it's usually a case of resetting the machine password via the netdom tool. If it's occuring on a workstation you may want to just remove it from the domain and add it back on, however if a server has the issue then this Microsoft article will help -
http://support.microsoft.com/kb/329721 (Description of netdom.exe Syntax and Versions)
http://support.microsoft.com/kb/260575 (How To Use Netdom.exe to Reset Machine Account Passwords / Domain Controller)