Monday, January 23, 2012

creating a CSR for a UCC SSL certificate on Exchange 2010 or SBS 2011

I installed an SBS 2011 box this weekend and I wanted to install a UCC SSL certificate on it. I get my certificates from godaddy, and this was the method I used in the Exchange Management Console to create the CSR that godaddy needed.


Here is the text in case that link ever gets moved or taken down:

Open the EMC

Select "Server Configuration" in the menu on the left, and then "New Exchange Certificate" from the actions menu on the right.
When prompted for a friendly name, enter a name by which you will remember this certificate in the future.

This name is not an integral part of your certificate request.

Under Domain Scope, you can check the box if you will be generating the CSR for a wildcard. Otherwise, just go to the next screen.

If you do select that box for a wildcard, skip to step 7.

In the Exchange Configuration menu, select the services which you plan on running securely, and enter the names through which you connect to those services, as prompted.

At the next screen, you will be able to review a list of the names which Exchange 2010 suggests you include in your certificate request. Review those names (using our SAN Name Help tool if necessary, and add any extra names at this point.

Your Organization should be the full legal name of your company.

Your Organization unit is your department within the organization.

If you do not have a state/province, enter the city information again.



Click "Browse" to save the CSR to your computer as a .req file, then Save, then Next, then New, and then Finish.
You should now be able to open the CSR as a notepad or wordpad file, and you will want to copy the entire body of that file into the online order process.

Tuesday, January 10, 2012

Corrupt PST handling (particularly > 2GB files on the old PST format)

I had a case where I exported an old mailbox from Exchange 2003 and could not access the file I exported. The mailbox was larger than 2 GB, but Exchange 2003 could only export 2 GB. When I tried to open the PST file in Outlook, I got "the [PST file] has reached its maximum size." and I wasn't able to open the PST.

Ugh.

I used the PST crop tool and tried to use scanPST - to no avail. The crop tool worked, but scanPST would fail and say it didn't make any changes to my cropped PST file. I tried cropping various amounts and running scanpst. I used a hex editor and altered some parts of the PST as I read other places. No success.

Reading through someone else's thoughts, I was able to use exmerge to import the PST back to an Exchange mailbox. I was able to do this *without* cropping the 2 GB PST.

This was very annoying, but eventually worked using exmerge. If that failed, I would have had to use one of the many paid PST recovery options. The fact that Exchange will export a corrupt PST is absurd. Why would there not be an error if it couldn't complete the export?

Wednesday, December 14, 2011

downloading hotfixes from Microsoft (in this case 943545 - storport)

I was attempting to get a hotfix for the storport driver for Windows Server 2003 x86, but the KB page wouldn't give me a link for it. After some research, I found that if you go this link:
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=943545&kbln=en-us

And then adjust the KB number in the URL, it'll take you to the appropriate hotfix. In my case, KB 943545 was what I was looking for.

The KB article gave no clue as to how to download the hotfix. Very annoying.

Saturday, December 3, 2011

shrinking the SBSMonitoring_log.ldf file

After taking steps to address the size issue of the SBS 2008 monitoring file as described here:

I found that my SBSMonitoring_log.ldf had grown to over 30 GB. The proper size is well less than 1 GB. What we need to do is shrink that LDF file. Here is what I did:

1. Open an elevated SQL Server Management Studio Express
2. Connect to the [servername]\SBSMonitoring database using Windows Authentication
3. Expand Databases and right-click on SBS Monitoring
4. Choose Tasks, then Backup
5. Make a backup of the current database
6. After backing up, right click SBSMonitoring and choose Tasks, Shrink, file.
7. In the opening window, choose Log in the File Type drop down list and click OK.
8. Now the SBSMonitoring_log.ldf file should shrink.


** of note, running the backup in step 4 is recommended, but I didn't run it as I was in a hurry to resolve this problem and it wasn't apparent to me where the backup would go. The C drive would be illogical as I had no space on the C drive. Given my time crunch (the low space on C was causing Exchange problems), shrank the file without backup and it did not cause any problems.

Friday, December 2, 2011

SBS 2008 Monitoring Database Fills to Capacity

On one of my SBS 2008 boxes, I began getting a ton of messages in my event log about the SBS 2008 monitoring database filling to capacity. You'll see events like this:

Log Name: Application
Source: MSSQL$SBSMONITORING
Date: 12/16/2009 4:15:47 PM
Event ID: 1827
Task Category: (2)
Level: Error
Keywords: Classic
User: SYSTEM
Computer: xxx.xxx.com
Description:
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Log Name: Application
Source: MSSQL$SBSMONITORING
Date: 12/16/2009 4:15:47 PM
Event ID: 1105
Task Category: (2)
Level: Error
Keywords: Classic
User: SYSTEM
Computer: xxx.xxx.com
Description:
Could not allocate space for object 'dbo.EventLog'.'PK_EventLog' in database 'SBSMonitoring' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.


This is resolved by using this process:

The description of the fix doesn't match the problem, but it works.

VERY IMPORTANT - this will make the SBSMonitoring_log.ldf very, very large. In my case, it made that file 30 GB, which ate up almost all the space on my C drive, which was a huge problem. See my next post on how to fix that.

Monday, November 7, 2011

moving Google Docs from one account to another

Functionality changes - so this data is really only relevant in and around late 2011.

I had a client with Google Apps that changed their company and domain name. As such, I created an entirely new account. I moved email, calendar, and contacts by downloading their email with the Google Apps Sync for Outlook, exporting to PST, and then uploading the data to the new mailbox.

But Google Docs wasn't so easy. You're supposed to be able to download all your Google Docs into a single ZIP file. But that wasn't working for me. So here is how I moved Google Docs from one Google Apps account to another that were in different domains.

On the old account, I used this utility to download the Google Docs into a single folder:

Now, I had all the docs in a single folder and they were all in the Word, Excel, PowerPoint, PDF, etc format.

Unlike their download function, Google's built in upload function was working fine. I clicked on the upload button and there were options for "file" and "folder." I chose the folder where I downloaded all the files using that utility above and it imported each Word file into a Google document and each Excel file into a Google spreadsheet, etc. I lost the collaboration information and the dates of the files, but I was able to keep the file content with relatively little trouble.

Tuesday, October 4, 2011

sending as an alias on an Exchange server

There's no easy way to send as one of your aliases on an Exchange server. Let's say your primary email address is dave@abc.com with two aliases of helpdesk@abc.com and dave@xyz.com. Logic would say that you could add the FROM field in your Outlook message and put in one of your aliases. Well, this doesn't work.

There are two workarounds to allow you to send as your aliases. I'll describe them both and give links on how to implement them:

1) create a POP3 account in the local Outlook that does not ever actually POP anything and uses the SMTP info for the Exchange server and the email address for the alias

2) create a distribution list with a single member (the user). Assign send as permissions to that mailbox for the user and then the user can use the FROM field. The down side is that you might be adding many different fake distribution lists for each time a user needs to send as an alias.


Both solutions are lame, but I'll be implementing option 1 from this point forward.