Exchange 2013 Resources

http://blogs.technet.com/b/rischwen/archive/2013/03/13/exchange-2013-mail-flow-demystified-hopefully.aspx

Mailbox Delegation in Office 365 for Small Business

The Small Business plans do not explicitly provide access to the EAC.  But you can do this by appending the correct EAC URL in your browser:

http://community.office365.com/en-us/wikis/exchange/4077.aspx

Info on how to set delegated mailbox access is here:

http://blogs.office.com/2013/09/04/configuring-delegate-access-in-outlook-web-app/

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

http://technet.microsoft.com/en-us/library/ff522363(v=exchg.150).aspx

For ongoing support please contact the Microsoft Support team per:

http://office.microsoft.com/en-nz/help/contact-support-for-technical-presales-billing-and-subscription-issues-HA103836042.aspx?redir=0

Recover NTFRS Issues - Including Active Directory Replication

This guy lays it all out: http://adfordummiez.com/?p=61

And here is a copy/paste in case he ever takes it down:

Environment:

- Windows 2000/2003/2008 domain controllers using FRS (not DFSR).
- More than one Domain Controller
- Atleast one DC with a healthy SYSVOL

Why do Journal Wraps occur?

Instan at the AD Troubleshooting blog made an excellent blog entry about:

“What happens in a Journal Wrap?”

You should give it a read to understand what is going on under the hood.

Symptoms that might occur:

• Event ID 13568 is logged in the NtFrs event log
• A generic Event ID 1058 may be logged
• You make changes to a logon script but not all users got the change
• Changing a GPO or creating a new GPO is not applied to all users or computers
• Missing SYSVOL share
• A RSoP or gpresult report that data or policy object is missing or corrupt

If you take a look at the 13568 event you’ll see that there is a “solution” to this problem:

Set the “Enable Journal Wrap Automatic Restore” registry parameter to 1

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters”

Restart ntfrs service.

This is not a good solution for post-Server 2000 SP3.
I don’t know why Microsoft still have this “how-to-fix” in event 13568, but they say in KB 290762:

Important: Microsoft does not recommend that you use this registry setting, and it should not be used post-Windows 2000 SP3. Appropriate options to reduce journal wrap errors include…

Update: I had to ask around about this since it was nagging me:

The event was never changed because the product group didn’t want to pay for the localization cost, nor admit that this registry setting caused more problems than it fixed. It actually came down to ego – the developer of FRS was a real piece of work. So instead the public docs were updated to state not to use that autorecovery registry setting.

Instead you should go for the Burflags method. This will kick start your SYSVOL up and running. Most often a “non-authoritative” (D2) approach will fix you up.

The “D2″ key can be set two places in registry:

Global re-initialization:

HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

or

Replica set specific re-initialization:

HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID
If you’re using DFS replica sets that holds a large amount of data that is healthy, go for the “Replica set specific re-initialization”. If you set the Global Burflags, FRS will re-initialize all replica sets, including the DFS namespace the member holds. If they hold a large amount of data… that might take some time.

To find the GUID of SYSVOL, look for the “Replica Set Name” named “Domain System Volume (SYSVOL SHARE)” under the subkey “HKLM\..\..\Replica Sets”:

This screenshot have only one GUID since I don’t use DFS in my lab.

Change the value of Burflags to D2 (hex).
If you don’t uses DFS you could just set the Global Burflags to D2. It will not make any difference under what subkey you set it. This will re-initialize all replica sets the member holds (in this case the SYSVOL).

After you have set the Burflags key to D2, you have to restart the NTFRS service on the affected DC.

Overview of what happens:

1. The Burflags is set to 0
2. Event ID 13565 is logged. non-authoritative restore has started
3. The content of SYSVOL are moved to the pre-existing folder
4. Event ID 13520 is logged
5. The local FRS database is rebuilt
6. It re-join (vvjoin) the replica set
7.  The “bad DC” will compare all files (file ID and MD5 sum) it has in the Pre-existing folder with the files from an upstream partner.
8. If a match is found, it will copy the file from the Pre-Existing folder to the original location. If they don’t match, it will pull the file from the upstream partner.
9. Event ID 13553 is logged
10. FRS notifies (SysvolReady reg.key = 1) the Netlogon service that SYSVOL is ready and can be shared.
11. The Netlogon service will share SYSVOL and Netlogon.
12. Event ID 13516 is logged (finished)

When you have verified that SYSVOL is shared and in sync, you can delete the content in the Pre-Existing folder to free up space.

Authoritative restore (D4):

If your SYSVOL is all messed up on every DC’s, you might have to do an “authoritative restore” using both the D4 and D2 values.

By the way you should never, ever use the D4 flag on more than one DC as you will have a lot of collisions and morphed folders. The D4 flag should only be set like Microsoft says, as a last resort.

Quick overview:

1. Stop the NtFrs service on every DC
2. Set the D4 flag on one DC that will be authoritative for the replica set(s). The SYSVOL content will not be moved to the pre-existing folder on the authoritative member.
3. Set the D2 flag on the other DC’s (non-authoritative)
4. Start the NtFrs service on the “D4″ DC.
5. Check that Event ID 13553 and 13516 is logged.
6. If step 5 is ok, start NtFrs on the “D2″ DC’s.

For detailed steps, see “How to rebuild the SYSVOL tree and its content in a domain”

References:

FRS event codes: http://support.microsoft.com/kb/308406

What happens in a Journal Wrap?
http://blogs.technet.com/instan/archive/2009/07/14/what-happens-in-a-journal-wrap.aspx

How to rebuild the SYSVOL tree and its content in a domain
http://support.microsoft.com/kb/315457

Using the BurFlags registry key to reinitialize File Replication Service replica sets
http://support.microsoft.com/kb/290762

Backing Up and Restoring an FRS-Replicated SYSVOL Folder
http://msdn.microsoft.com/en-us/library/cc507518(VS.85).aspx

Allow Non-Admin Users to Install Print Drivers for Shared Network Printers

Configure Group Policy settings in Computer\Administrative Templates\Printers\Point and Print Restrictions
See also Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Devices: Prevent users from installing printer drivers

OWA 2010 Website Is Blank

After you install update rollups on Exchange 2010 it is common to get a blank white OWA page when browsing to the OWA page.


the URL will show something like the following "https://mail.mydomain.com/owa/auth/logon.aspx?url=https://mail.mydomain.com/owa/&reason=0 ."

To fix this issue you must run the Exchange Management Shell and execute the updatecas.ps1 command from the "C:\Program Files\Microsoft\Exchange Server\V14\Bin" folder. This will fix your issue, it causes the owa install to complete correctly.

References:
Blantantly ripped off from this site
http://www.prestigecomputersolutions.com/knowledge-base/entry/exchange-2010-owa-blank-white-screen-fix.html

Uninstall WSUS

http://social.technet.microsoft.com/Forums/en-US/f447e7d6-7007-4eb6-b38b-90f92525e092/how-to-uninstall-wsus?forum=winserverwsus

Backup Exec Backup-to-Disk Best Practices

Requirements for creating a backup-to-disk folder:

Backup-to-disk folder can be created in any of the following locations: 

• NTFS partitions (local or remote) and External USB Hard Drives.
  • The backup-to-disk folder must exist on an NTFS partition for backup jobs in which the Granular Recovery Technology(GRT) option is selected. This option is available for Microsoft Exchange databases and storage groups, Microsoft Active Directory, Microsoft Hyper-V machines, VMware Virtual Machines, and Microsoft SharePoint content database and Team database.
• Distributed File System (DFS) shares. 
• FAT/FAT32 partitions(local or remote). 
• Veritas Volume Manager partitions. 
• RAID drives with any configuration. 
• NFS volumes.
• Network Attached Storage (NAS) devices.
  • If a NAS device is emulating a Windows operating system, contact the NAS manufacturer for assistance before creating backup-to-disk folders on the NAS device. Symantec does not certify NAS devices. If the operating system is a proprietary operating system and not a true Windows operating system, Symantec cannot properly troubleshoot the device.

Recommendations for the "Backup to Disk" feature:

Minimizing Fragmentation:

• Avoid hosting multiple backup-to-disk folders on the same volume.
• Minimize the number of concurrent backup operations. Allow only one operation for maximum control.
• Maintain at least 30 percent free space, and avoid allowing the disk to become completely full.
• Avoid hosting other applications on the same volume.
• To prevent fragmentation a regular defragment operation should be performed on all backup-to-disk volumes.
• Maintain 10% or less total volume fragmentation.
• Perform a CHKDSK on the volume.

Performance:

• Do not allocate the maximum size of the backup-to-disk files when performing a GRT enabled backup.
• All backup-to-disk locations should be excluded from antivirus/antispyware scans.
• Destination drives that are setup with RAID 5 can show degraded performance. RAID 10 has been shown to significantly improve overall performance. In some cases, RAID 10 offers faster data reads and writes than RAID 5 because it does not need to manage parity.
• Use high RPM drives in all backup-to-disk volumes for best performance.
• Maximize the available memory. The amount of available memory will impact backup speed. Insufficient memory, improper page file settings, and a lack of available free hard disk space will cause excessive paging and slow performance.
• Do not use Microsoft Windows compression or encryption on the volumes hosting the backup-to-disk folder.
• Experiment with the options for buffered reads and buffered writes. Enabling these options may increase backup performance depending on the underlying disk structure implemented.

Guidelines:

• All Backup to Disk jobs should be overwrite operations.
• Calculate disk space requirements before assigning a disk space threshold.
• Create a separate backup-to-disk folder specifically for all GRT enabled backup jobs. Note: Backup Exec 2012 enforces one disk storage device per Windows volume, as such this will need multiple volumes
• Erase media from the Backup Exec console do not use Windows Explorer to delete Backup Exec data, unless it has already been properly removed from the application. For more information on deleting media properly please review the related articles section.
• The size of Backup to disk files should not be set larger than 4GB.  This is the default size for backup-to-disk files in all current Backup Exec releases.  The larger the file size the more data is exposed when that file is corrupted.
• USB/eSATA drives are not removable media, and should not be used as such.

   

Note:- For more information please refer to the Administrator’s guide and/or Hardware Compatibility List(HCL) pertaining to the Backup Exec version being used.

References:
http://www.symantec.com/business/support/index?page=content&id=TECH164267