Wednesday, October 28, 2009
Wednesday, September 9, 2009
We recently ran into an issue where using a new Digicert certificate essentially broke activesync for most people in the company. The issue is that the new root certificate for Digicert isn't compatible with older browsers and devices (they don't come standard with the new root certs for Digicert like they might with Verisign and others). The primary phone of the organization was a Motorola Q, which made the issue quite visible.
The problem boiled down to this root cert taking precedence over the intermediate cert (Digicert calls it eclipsing which I suppose is a more valid term), which would have worked fine. After the Digicert Root Cert was removed, the issue was resolved.
Note: Be sure that the intermediate is in place and functioning or else you will break all of the modern phones and browsers as well.
Also as an alternative fix, you could install the root cert on the phones in question. This is more labor intensive, but might be viable if there are only a few old straggler phones floating around.
You can also run a good test for this and other issues at:
Recently we had an issue with an Exchange server constantly rebooting. The symptoms were extremely indicative of virus infection. Terminations of LSASS.exe, timed reboots, and permission revocations, were all occurring, and so we were immediately assuming Sasser/Blaster.
It then began to seemingly cause issues with domain communication. Upon checking the system properties, the domain registered as *Unknown* and it was nearly impossible to perform any action as all permissions had been stripped (we were using a domain account so this sort of made sense).
After having a local tech bounce the box and login with the KVM, the issue seemed resolved for these domain level issues, and we never saw them again. The original LSASS issues and reboots continued, however. Not wanting to waste any more time, we gave PSS a call. They informed us that a patch we had installed, KB968389, was likely causing the issue. Despite passing our patch testing and being installed on numerous other environments, MS told us that they have been informed of other sites experiencing the same issue. Removing the patch resolved the issue.
In summary.. KB968389 = Bad if you like a stable environment
Tuesday, June 9, 2009
Monday, May 18, 2009
Tuesday, May 12, 2009
SATA disks can be great for Exchange 2010 depending on the deployment!
Tuesday, April 14, 2009
More to come despite my recent drought..
Friday, March 20, 2009
Wednesday, March 4, 2009
Thursday, February 19, 2009
Not my best writing, but you all know how on-the-job technical writing goes. Information gets stripped, vocabulary cut down, etc. :)
It was posted on Computer Technology Review. You can check it out here.
Sunday, February 15, 2009
Wednesday, February 11, 2009
Wednesday, February 4, 2009
Custom Volumes are good when you’d like to offload a backup of something to a specific place rather than using the disk pools. My example was that the current backup location was on the same filer as my source data. I wanted to offload this single application’s backups to a separate SAN than the source data in order to have the ability to recovery from a hardware failure. There may be reasons to use this for Exchange, but I would avoid as disk pools are more seamless. The planning for a deployment of Exchange should account for this. My example is backing up archives.
The prerequisites are that you have available storage, the DPM agent installed on the target, and the needed VSS hotfix on the target.
1. Create storage
a. Carve out a volume/lun (or use DAS)
b. Attach that storage to the machine via iSCSI, a VHD hard drive if virtual, or whatever other means.
2. Figure out how much space you need for your volumes.
a. You can follow the MS guidelines using the calculator:
b. OR you can just use DPM to pull what you’ll need. This only applies to backing up current data, with however many recovery points you need. You will want to tack some extra on for growth.
i. Create a new protection group.
ii. Choose the data you want to protect
iii. Choose your retention
iv. Click modify
v. These are the values for today, so leave some overhead.
3. Carve out your two volumes; one for replica, one for recovery point.
a. Right click the unallocated space, and choose New volume..
b. Choose Simple (other options may not be grayed out)
c. Choose the Size – I had 200gb to play with, so I allocated 160 to replica and 40 to recovery point.
d. Rinse repeat for the other. This does not have to be on the same disk.
4. Create the Custom Volume and Protection Group
a. Go back to DPM and create the Protection Group as we outlined before.
b. Pull down the menu for storage, and choose custom volume
c. Assign the replica volume and recovery point volume to their respective places. Leave it at no formatting.
d. Choose manually as it is your only option.
e. Click create group (ignore the values in the box..)
f. Once this is all done, you must just manually create the new replica (Perform consistency check), and you’re set!
In order to expand storage with this configuration, you cannot use DPM, but rather you must use standard windows disk management. I realize there are no screenshots, but it was a disaster with the formatting on this blogger. I will make them available upon request.
Tuesday, January 27, 2009
The known work-arounds for this issue are to use Outlook 2007, or run Outlook with the /cleanrules switch. You will, of course, want to export your rules first just in case.
Unfortunately RIM does not support the OOO feature (a phone call from our NOC to RIM discovered this) which was technically re-written in Exchange 2007. They supposedly released a fix in a service pack, but the BES in this case had the service pack which does not increase my faith in RIM despite the love I harbor for its constant desire for attention (reboots).
Monday, January 12, 2009
If you get the following while sending to an internal recipient, chances are you haven’t set your environment to accept for the domain you are sending to.
Your message did not reach some or all of the intended recipients.
Subject: Subjects are fun!
Sent: 1/1/2009 1:00 PM
The following recipient(s) could not be reached:
Lastname, Firstname on 1/1/2009 1:00 PM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
The example that prompted me to post this was one where admins were adding SMTP addresses on to their users for domains that they weren’t configured to be responsible for. How do we solve this? In this case the servers were Exchange 2003, so we will start there. We need to open ESM, navigate to Recipients -> Recipient Policies
Right click and choose New -> Choose E-Mail Addresses
Navigate to the E-Mail Addresses (Policy) tab, click New, and choose SMTP Address.
Enter an example SMTP address with domain you'd like to be able to send to.
Enter a name and select who you'd like to automatically receive this policy (I left mine blank as they wanted to sporadically assign the e-mail address as needed.)
Click OK. it should ask you to run this policy now, but if it doesn't you may right click your new policy and choose 'Apply this policy now...'
In Exchange 2007 you need only make your Exchange organization authoritative for the domain in question. The place to do this is under Organization Configuration -> Hub Transport -> Accepted Domains tab.
Add your domain here as authoritative and it will accomplish the same feat.
There are other causes for this issue, but this is the most common from what I have seen.
Tuesday, January 6, 2009