Some Notes on the Machines

There is a lot of talk about this on the wild Web. This situation occurs because some instances of Microsoft SQL default to “FULL” logging mode, and this can be very helpful because if there is a crash, the database can be restored to the very transactional instant of the crash. In “FULL” logging mode, the LDF file keeps on piling up until an SQL-aware system backup is performed, at which time the LDF is pared down automatically.

But there are many SQL databases out there where we don’t care about transaction-level restore, where the backup is system image-wide and we are very happy with that level of restoration. In this case, “FULL” logging mode is very wasteful, because since the backup is not SQL-aware, the LDF file keeps on piling and piling, taking many gigabytes of disk space.

For these we want “SIMPLE” logging mode. To set this up, log into SQL Studio using an appropriately high-privileged user, and run this query substituting database_name appropriately:

USE master;
ALTER DATABASE database_name SET RECOVERY SIMPLE ;
CHECKPOINT;

Two things are accomplished by the above. First, the LDF will quit piling. Second, a CHECKPOINT was done, which tells SQL Studio immediately that most of the space in the huge LDF is wasted. This means that you can tell SQL Studio to shrink the LDF, eliminating the wasted space, like this:

• In Databases, right-click on the database whose LDF needs shrinking
• Click Tasks —> Shrink —> Files.
• In File type, choose Log.
• Make sure “Release unused space” is selected. The other numbers will make it obvious how much space you are freeing up. If they’re not good, you have something else wrong or undone!
• Click OK. The shrinkage will begin. Depending on how much is to be done, it may take a while, but the progression will show up in free disk space recorded in CMD.

At least initially, one must:

1. Load up adsiedit.msc,
2. Find a user object,
3. Get its properties,
4. Click on anything in the list,
5. Press P on the keyboard,
6. Scroll to proxyAddresses and edit it,
7. Set the primary address as SMTP:email@domain.com (note the caps in the prefix),
8. Set all alias(es) as smtp:email2@domain.com (note the lowercase prefix!).

In some environments, a new tab appears in ADUC which means you don’t have to go back to ADSI Edit, but this is not always the case.

Some very interesting info:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/1b926c85-b866-464b-9590-70506ba9d8ce/vss-issue-event-id-22-12289-12293-error-0×8004230f-failed-to-retrieve-volumes-that-are-eligible?forum=windowsbackup

https://msdn.microsoft.com/en-us/library/windows/desktop/bb891959#mindiffareafilesize

Here are some steps and info:

http://www.storagecraft.com/support/kb/article/32

Here is a Fix-It from Microsoft for Server 2003, which runs quite a few steps automatically, and does not (this is new) necessarily require a reboot:

http://support.microsoft.com/kb/940184

And lastly, here is a patch from Microsoft which can help a lot in Server 2003, even on fully-updated machines:

http://support.microsoft.com/default.aspx?scid=kb;en-us;891957

This command does it for everything Sent after 9/22/2016 and before 9/27/2016. You’ll then have to export it from the temporary_storage_mailbox, and import it into original_mailbox.

This is all one command line in Exchange PowerShell, set as multiple lines for easy reading. The SearchQuery is especially arcane; there is a lot of incorrect syntax out there for it, the below worked today (2016-09-27) on Exchange 2010 fully updated.

Search-Mailbox -Identity original_mailbox@domain.com 
-TargetMailbox temporary_storage_mailbox@domain.com 
-TargetFolder "Rescued_From_Dumpster" 
-SearchQuery {Sent:>22-Sep-2016 AND Sent:<27-Sep-2016}
-SearchDumpsterOnly

Here’s a great tool, free of charge:

http://www.vaita.com/ODIR.asp

Here are instructions for adding the domain admin you are using, to the appropriate Exchange roles:

https://technet.microsoft.com/en-us/library/dd638143

And the role changes you need, are listed here:

http://notes.ponderworthy.com/copy-an-exchange-online-mailbox-to-another-in-powershell

“Sync Issue” messages, especially “Conflicts”, can pile up in Exchange mailboxes when Outlook is used. There is a server-side method of handling this:

1. In the Exchange console, under Organization Configuration, under Mailbox,
2. Create a Retention Policy Tag, tag type Sync Issues, age limit 3 days. Set Action to Take as Permanently Delete.
3. Create a Retention Policy using the above Tag. Add any or all involved mailboxes, to it.

Sometimes when attempting to upgrade or reinstall AOL, it will state that there is other communication software running which is preventing the install. The popup involved says this in long form, starting with “Your computer is running communication software that cannot”. Just now, an AOL tech showed me this method of easily overriding this. First, run the following:

sinf

This brings up the “AOL System Information” tool. Click on Utilities on the left column of buttons. Then, under “AOL Utilities”, click “Close AOL” to the right of the words “Close All AOL Programs”, and then click “Start” to the right of the words “AOL Process Shut Down”. You won’t get any feedback from either. But once these are done, shut down sinf, and try your install again.

This is otherwise entitled “How to install Exchange 2010 service packs and roll-ups without risk of bootlooping the server”, by Mike Hunsinger.

The method below has worked perfectly on several servers and has not caused a recovery situation. That said, assure there’s good backups and perform these procedures word-for-word as these Exchange updates have been known to bootloop and bluescreen servers, particularly SBS servers when not cleanly installed.

You will need this web page or one of a few like it, to determine the current patch level of the Exchange in front of you.

The key is to determine the current Exchange SP level, then based on the current version, plan your updates like this: First, install the highest-level rollup for the current SP. Then install the next SP by version. Followed by that SP’s highest-level rollup, then the next SP.

Here’s an example:

Your 2010 Exchange Server is using SP1 RU 3 (Roll-Up3). You intend to upgrade this system to SP3 RU14 (Latest version of Exchange).

Here’s the order in which you should install the updates based on this exchanges current version:

1. Update Rollup 8 for Exchange Server 2010 SP1 (Highest version of SP1)
2. Exchange Server 2010 SP2
3. Update Rollup 8 for Exchange Server 2010 SP2 (Highest version of SP2)
4. Exchange Server 2010 SP3
5. Update Rollup 14 for Exchange Server 2010 SP3 (Highest version of SP3)

Notes we’ve found are important:

• Assure the server’s OS itself is running the latest service pack for Windows Server.

• Exchange SP’s must be downloaded from the web and installed using an exe. Roll-Ups must only be installed via Windows Update.

• Using this pattern of installs and installing Roll-Ups using only Windows Update, will prevent having to perform the lengthy staging process where the mailbox databases are manually converted between versions using CMD.

• Completely review the prerequisites for each Rollup and SP before installing it. There are corroborative softwares such as .net and sql client or certain hotfixes that may need to be installed prior to a given service pack or roll-up.

• During the Service Pack updates, you will see a long checklist the server is moving down while performing the upgrades. If the server errors on one of the checklist items and asks if you wish to continue or roll-back. ROLL IT BACK. Resolve the issue noted and try the update again. You want all 10 lights green when it hits the bottom of the checklist. Errors here are usually the result of insufficient permissions someplace in the server. The errors are usually easy to trace down online.

• Between every update listed. Launch the ECM. Assure the mailboxes are all listed. Then run the builtin Exchange testing. If Exchange says it’s passed, move onto the next update. If Exchange fails any factors, they must be eliminated before continuing.

• Allow up to 1 hour for the server to reboot following an Exchange SP Upgrade. It’s advisable that ILO be activated prior to installing the upgrades described in this document, so you can keep an eye on the server while it reboots.

Here’s a great resource:

http://blog.powershell.no/2010/09/20/managing-calendar-permissions-in-exchange-server-2010/