Differences Between FOPE and EOP

When customers using Forefront Online Protection for Exchange (FOPE) are upgraded to Exchange Online Protection (EOP), including Exchange Online and FOPE-standalone customers, there are behavior changes and feature differences to take note of, such as:

 

Quarantine access - In FOPE, end users and administrators could access the FOPE quarantine. In EOP, only administrators can access the EOP quarantine in the Exchange admin center. However, end users can self-manage their own spam-quarantined messages via end-user spam notifications;

 

Deferral notifications - FOPE could be configured to notify an administrator if an inbound message was deferred by the service. EOP does not currently have deferral notifications;

 

Multiple domain support - In FOPE, you used virtual domains to configure policy rules to apply to a specific group and route messages to a specific site. In EOP, you can route messages to a specific site by using transport rules and connectors. For instance, you can create an Outbound connector with criteria based routing enabled to deliver messages to a specific site. You can select this connector for use in a transport rule that is triggered based on a particular attribute in the transport rule predicate, such as the City property type;

 

Directory synchronization - The Office 365 DirSync tool replaces the FOPE DirSync tool;

 

Directory-Based Edge Blocking - In FOPE, the Directory-Based Edge Blocking feature enables administrators to reject email going to non-existent users in their organization rather than accept the message and try to deliver it or send it to the spam quarantine. In EOP, Directory-Based Edge Blocking is currently not supported;

 

Partner and reseller administration - If you are a Microsoft partner or reseller, and you sell EOP to your customers, you can request permission to administer their account within the Office 365 admin center. This is known as delegated administration, and it allows you to configure their EOP settings as if you were an administrator within their organization. (In the new Office 365, there isn’t a separate user interface for company administration.);

 

Connection filter IP Allow list - In FOPE, the IP Allow list was respected end-to-end only for single IP addresses. EOP's IP Allow list is respected end-to-end for single IP addresses and CIDR ranges from /32 to /24. For example, 65.55.39.10/26;

 

FOPE connectors and spam filtering - When you created or edited a FOPE connector, you could make selections to bypass spam filtering and policy-rule filtering. In EOP, you can't configure a connector to bypass filtering. Instead, Microsoft recommends that you use the connection filter's IP Allow list to bypass all spam and policy filtering;

 

Disabling anti-malware protection - The FOPE Administration Center allowed you to disable malware filtering. In EOP, malware filtering is automatically enabled for all customers. There is no way to disable it;

 

Exchange Enterprise CAL with Services - If you are an Exchange Enterprise CAL with Services customer, and you use EOP to protect your on-premises mailboxes, two additional features are available to you: Data Loss Prevention (DLP) and Remote Windows PowerShell administration. DLP helps you identify, monitor, and protect sensitive information in your organization through deep content analysis. Using Remote Windows PowerShell, you can manage your cloud features by running scripts from the command line. There is more information about EECAL with Services licensing and its included features in the Exchange Online Protection Overview.

 

Source: Office 365 Community

 

Migrating Public Folders to Exchange 2013

Now that Exchange 2007 SP3 RU10, Exchange 2010 SP3 and Exchange 2013 CU1 have been released, administrators can start deploying Exchange 2013 in a coexistence scenario with these two previous versions of Exchange.

 

Part of many transitions from Exchange 2007/2010 to 2013 will include the migration of Public Folders (PFs). Because of all the major changes made to PFs, discussed in the Exchange 2013 Preview - Public Folders article, legacy Exchange mailboxes are unable to access the PF hierarchy on Exchange 2013 servers. However, mailboxes on Exchange 2013 can connect to legacy PFs.

 

Unlike migrating PFs between previous versions of Exchange, PFs on Exchange 2013 and legacy PFs cannot coexist in an Exchange organization, which means that migrating PFs to Exchange 2013 is a one-time cut-over process.

 

Because legacy mailboxes cannot access PFs in Exchange 2013, it is recommended that all mailboxes are first moved to Exchange 2013 and only then PFs migrated.

 

The high level process for migrating Public Folders from Exchange 2007/2010 is as follows:
   1. Migrate user mailboxes to Exchange 2013 before migrating PFs;
   2. Snapshot current PF environment for comparison when migration is complete (folders, sizes and permissions);
   3. Create CSV file, manually or using scripts (Export-PublicFolderStatistics.ps1 and PublicFolderToMailboxMapGenerator.ps1). End result is a CSV file mapping PFs to new PF mailboxes;
   4. Create PF mailboxes using New-Mailbox –PublicFolder cmdlet;
   5. Migrate PF content using New-PublicFolderMigrationRequest cmdlet;
   6. Lock down Exchange 2007/2010 PFs for final migration using the following cmdlets:
         a.      Set-OrganizationConfig –PublicFoldersLockedForMigration $True (Exchange 2010)

         b.      Set-OrganizationConfig –PublicFolderMigrationComplete $True (Exchange 2013)

         c.      Set-PublicFolderMigrationRequest <name> -PreventCompletion $False (Exchange 2013)

         d.      Resume-PublicFolderMigrationRequest <name> (Exchange 2013)

   7. Test new PFs;
   8. Snapshot Exchange 2013 PFs and compare with Exchange 2007/2010 PF snapshots;
   9. Roll back, if necessary, by running Set-OrganizationConfig –PublicFoldersLockedForMigration $False and Set-OrganizationConfig –PublicFolderMigrationComplete $False;
   10. Remove Exchange 2007/2010 PFs and PF databases.

For a detailed explanation, including step by step instructions, please check MSExchange.org and the Migrating Public Folders to Exchange 2013 article.

Update-MailboxDatabaseCopy in Exchange 2013 CU1

The Update-MailboxDatabaseCopy cmdlet is used to seed or reseed a mailbox database copy. Seeding is the process in which a copy of a mailbox database is added to another Mailbox server, thus becoming the database copy into which copied log files and data are replayed. This cmdlet can also be used to seed a content index catalog for a mailbox database copy.

In Exchange 2013 CU1 this cmdlet includes some new parameters that are designed to aid with automation of seeding operations. These parameters include:

• BeginSeed – this is useful for scripting reseeds. With this parameter, the task asynchronously starts the seeding operation and then exits the cmdlet;
• MaximumSeedsInParallel – this is used with the Server parameter to specify the maximum number of parallel seeding operations that should occur across the specified server during a full server reseed operation. The default value is 10;
• SafeDeleteExistingFiles – this is used to perform a seeding operation with a single copy redundancy pre-check prior to the seed. Because this parameter includes the redundancy safety check, it requires a lower level of permissions than the DeleteExistingFiles parameter, enabling a limited permission administrator to perform the seeding operation;
• Server – this is used as part of a full server reseed operation to reseed all database copies in a Failed and Suspended state. It can be used with the MaximumSeedsInParallel parameter to start reseeds of database copies in parallel across the specified server in batches of up to the value of the MaximumSeedsInParallel parameter copies at a time.

Remember that you must suspend a database copy before you can update it using the Update-MailboxDatabaseCopy cmdlet.

DirSync Password Synchronization

The latest version of the Windows Azure Active Directory (WAAD) Sync Tool, also known as DirSync, has just been released.

Besides supporting Windows Server 2012, this new version provides the much anticipated Password Sync feature, which enables users to log into their Azure Active Directory services (such as Office 365, InTune, CRM Online, etc.) using the same password as they use to log into their on-premises network.

However, this should not be seen as a replacement for ADFS. Rather, it is an alternative for organizations that find it sufficient to have users using the same password in Office 365 as in the on-premises Active Directory. ADFS provides many other features that this tool does not, one of them being Single-Sign On (SSO) where users only need to authenticate once when they are logged on to a domain-joined client machine. With this new tool, and without ADFS, users will get prompted for credentials when accessing Office 365 resources even if they are on a domain-joined machine. The advantage is that the username and passwords are the same, and when users update their credentials on Active Directory, the password will get synchronized to WAAD. This tool does not provide SSO because there is no token sharing/exchange in the Password Sync based process.

How Password Sync Works
The Active Directory Domain Service stores passwords in form of a hash value representation of the actual user password. The Password hash cannot be used to login to an on-premises network and it is also designed so that it cannot be reversed in order to gain access to the user’s plaintext password. To synchronize a password, the Directory Sync tool extracts the user password hash from the on-premises Active Directory. Additional security processing is applied to the password hash before it is synchronized to the Azure Active Directory Authentication service. The actual data flow of the password synchronization process is similar to the synchronization of user data such as DisplayName or Email Addresses.

Passwords are synchronized more frequently than the standard Directory Sync window for other attributes. Passwords are synchronized on a per-user basis and are generally synchronized in chronological order. When a user’s password is synchronized from the on-premises AD to the cloud, the existing cloud password will be overwritten.

When the Password Sync feature is first enables in DirSync, it will perform an initial synchronization of the passwords of all in-scope users from the on-premises Active Directory to Azure Active Directory. You cannot explicitly define the set of users that will have their passwords synchronized to the cloud. Subsequently, when an on-premises user changes their password, the Password Sync feature will detect and synchronize the changed password, most often in a matter of minutes. The Password Sync feature will automatically retry failed user password syncs. If an error occurs during an attempt to synchronize a password the error is logged in event viewer.

The synchronization of a password has no impact on currently logged on users. If a user that is logged into a cloud service also changes their on-premise password, the cloud service session will continue uninterrupted. As soon as the cloud service session expires, the user has to re-authenticate using the new password.

Security Considerations
When synchronizing passwords using the password sync feature, the plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Additionally, there is no requirement on the on-premises Active Directory to store the password in a reversibly encrypted format. A digest of the Windows Active Directory password hash is used for the transmission between the on-premises AD and Azure Active Directory. The digest of the password hash cannot be used to access resources in the customer's on-premises environment.

Password Policy Considerations
There are 2 types of password policies that are affected by enabling password sync:

• Password Complexity Policy: when you enable password sync, the password complexity policies configured in the on-premises Active Directory override any complexity policies that may be defined in the cloud for synchronized users;
• Password Expiration Policy: if a user is in the scope of the password sync feature, the cloud account password is set to "Never Expire". This means that it is possible for a user's password to expire in the on-premises environment, but they can continue to log into cloud services using this expired password. The cloud password will be updated the next time the user changes the password in the on-premises environment.

Enabling Password Sync
Password Sync is enabled when running the Directory Sync tool Configuration Wizard. When prompted by the Wizard, select the “Enable Password Sync” checkbox. This process will trigger a full synchronization which generally takes longer than other sync cycles to complete.

NOTE: DirSync is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature will not function correctly if DirSync is installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported).

 

The new version of DirSync (v1.0.6385.0012) can be downloaded from your respective Office 365 Admin portal or from here.