I’ve done plenty of new self-signed certificates for Exchange. Most places don’t mind if the certificate displays an error when users visit the webmail site (OWA), but they do mind if the users receive an error saying the certificate name is invalid when using Outlook.

Had the self-signed certificate installed on a standard Exchange 2007 server. CRM 4 requires an SSL/TLS connection. While we could have created another internal certificate with the export = $true key, the customer also wanted to rid themselves from the invalid certificate when browsing to the Outlook Web Access site.

Obviously replace “domain.tld” with your actual information.

Create the certificate request:

Open PowerShell on Exchange
New-ExchangeCertificate -DomainName webmail.domain.tld,other.domain.tld,autodiscover.domain.tld -FriendlyName "Site Webmail Certificate" -GenerateRequest:$True -Keysize 2048 -path c:\Webmailcertificate.txt -privatekeyExportable:$true -subjectName "c=US, o=CompanyName Inc., OU=IT, L=City, S=State, CN=webmail.domain.tld"

Purchase the site certificate:

Go to your favorite SSL supplier (Verisign, Thawte, etc.) and purchase an SSL Certificate. Standard is fine for this mostly internal-only site.
Paste the code from c:\Webmailcertificate.txt when applicable
After the certificate has been authorized, download the .crt certificate and the intermediary Certificate Authority files

Install your certificate:

Back on PowerShell for Exchange
Import-ExchangeCertificate -path c:\webmailcertificate.txt
Get-ExchangeCertificate
Copy the Thumbprint from the NEW certificate (probably the one with “…..” listed under Services
Enable-ExchangeCertificate -Services IMAP, POP, UM, IIS, SMTP -Thumbprint 896B74B2YourExchangeThumbprintFC6A7
Click Y for Yes if prompted to replace from an old(er) certificate

Now your webmail access (OWA) should no longer have a certificate issue. However, if the issued name on the certificate is DIFFERENT from your NETBIOS name of your email server, you will have issues INTERNALLY. Namely, all of your outlook clients will report a certificate is invalid error – that the names do not match. This is because the Exchange Server now has the certificate that points to webmail.domain.tld and your outlook clients are pointing to exchange07.domain.local.

To fix this issue:

Once again, use PowerShell for Exchange
Get-ClientAccessServer
Copy the servername
Set-ClientAccessServer -Identity SERVERNAMEHERE -AutodiscoverServiceInternalUri https://webmail.domain.tld/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "SERVERNAMEHERE\EWS (Default Web Site)" -InternalUrl https://webmail.domain.tld/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "SERVERNAMEHERE\oab (Default Web Site)" -InternalUrl https://webmail.domain.tld/oab
There is one final step required – recycle the MSExchangeAutodiscoverAppPool:
On Exchange 2007, Open IIS Manager
Navigate to Local Computer > Application Pools
Right-Click on MSExchangeAutodiscoverAppPool and select Recycle

That should be it. Everything works here after recycling.

Or you could always just put in the required domains on your certificate request:
NetBIOS name
FQDN external (if different)
autodiscover.domain.tld
autodiscover.domain.local (if applicable)
webmail.domain.tld (obviously change accordingly)

Adding a new user to exchange? Notice that the new user doesn’t show up in Outlook?

Open up the power shell on your Exchange server (or connect remotely to it), and run the following command:

Update-OfflineAddressBook "Name of Address Book"

Or

Get-OfflineAddressBook | Update-OfflineAddressBook

Then, if you’re in cached mode (most are), you can go to Tools, Send/Receive, and then select Download Address Book
Uncheck Download changes since last Send/Receive and hit OK
Now you should have the new user in your address book!

I remember at my last job I had to upgrade from Exchange 2003 to Exchange 2007. It wasn’t that huge of a deal actually. Then I had a customer who wanted to upgrade to 2007. That was a much larger problem as the customer did not have an abundance of hardware/time/patience. In place installations/upgrades are almost always more tedious than a fresh install. Oh well, live and learn.

Anyway, after upgrading my third client to 2007 Exchange, I remember that I had a tool to help with permissions of all/some of the mailboxes. Namely the HR manager required permission to view all of the calendars of every employee. OK, I can do that.

Grab a file from Microsoft called PFDAVAdmin. This stands for Public Folders DAV-based Administration Tool.

Now, I had another problem after installing said program (it’s just an extraction, so don’t worry about it screwing anything up):
Could not expand https://servername/mailboxstore/Username/L...20Folders/: Name cannot begin with the '0' character, hexadecimal value 0x30. Line 1, position 402."

Argh. Someone mentioned to me that I should remove the SSL requirement on the public folders area. Lot of good that does, as the problem was expanding the folders for individual mailboxes. As it turns out, you need .net 1.1 installed. I was trying to run this from the Exchange 2007 Server directly. Runs great from the old Exchange 2003 server.

So, open this program up. Then click File, Connect.
If you can’t figure out what to put under Exchange Server or Global Catalog, then you should find a file called ADChecker (it’s in the Downloads Section)
If you just want to edit permissions of the public folders, keep the radio on Public Folders. I needed to alter the rights for a single mailbox user remotely. So I chose All Mailboxes.
After a brief query time, you should see Mailboxes with a plus sign. Drill down to your user, then Top of Information Store, Then Calendar.
Right-click and select folder permissions.

Next you can click Add and then add a user after searching.
The permission layout is the same as standard public folders for Exchange.

I may or may not clean this up and add more screen shots.