Exchange Server Hybrid Deployments

A hybrid deployment provides the seamless look and feel of a single Exchange
organization between an on-premises Exchange organization and Exchange Online
in Microsoft Office 365. A hybrid deployment offers organizations the ability to extend the
feature-rich experience and administrative control they have with their existing on-premises
Microsoft Exchange organization to the cloud.

Exchange hybrid deployment features

Secure mail routing between on-premises and Exchange Online organizations.

Mail routing with a shared domain namespace. For example, both on-premises and
Exchange Online organizations use the @contoso.com SMTP domain.
A unified global address list (GAL), also called a shared address book."
Free/busy and calendar sharing between on-premises and Exchange Online
organizations.
Centralized control of inbound and outbound mail flow.
A single Outlook on the web URL for both the on-premises and Exchange Online
organizations.
The ability to move existing on-premises mailboxes to the Exchange Online
organization. Exchange Online mailboxes can also be moved back to the on-premises
organization if needed.
Centralized mailbox management using the on-premises Exchange admin center
(EAC).
Message tracking, Mail Tips, and multi-mailbox search between on-premises and
Exchange Online organizations.
Cloud-based message archiving for on-premises Exchange mailboxes. Exchange
Online Archiving can be used with a hybrid deployment.

Exchange hybrid deployment considerations

You should consider the following before you implement an Exchange hybrid deployment:
Hybrid deployment requirements Before you configure a hybrid deployment, you need
to make sure your on-premises organization meets all of the prerequisites required for a
successful deployment.
Exchange ActiveSync clients When you move a mailbox from your on-premises
Exchange organization to Exchange Online, all of the clients that access the mailbox need to
be updated to use Exchange Online; this includes Exchange ActiveSync devices. Most
Exchange ActiveSync clients will now be automatically reconfigured when the mailbox is
moved to Exchange Online, however some older devices might not update correctly.
Mailbox permissions migration On-premises mailbox permissions such as Send As,
Receive As, and Full Access that are explicitly applied on the mailbox are migrated to
Exchange Online. Inherited (non-explicit) mailbox permissions and any permissions on nonmailbox objectssuch as distribution lists or a mail-enabled userare not migrated.
Therefore, you have to plan for configuring these permissions in Office 365 if applicable for
your organization. For example, you can use the Add-RecipientPermission and AddMailboxPermission Windows PowerShell cmdlets to set the permissions in Office 365.

Support for cross-premises mailbox permissions Exchange hybrid deployments

support the use of the Full Access mailbox permission between mailboxes located in an onpremises Exchange organization and mailboxes located in Office 365. A mailbox on an onpremises Exchange server can be granted the Full Access permission to an Office 365
mailbox, and vice versa. For example, an Office 365 mailbox can be granted the Full
Access permission to an on-premises shared mailbox.
Offboarding As part of ongoing recipient management, you might have to move Exchange
Online mailboxes back to your on-premises environment.

Exchange hybrid deployment components

A hybrid deployment involves several different services and components:

Exchange servers At least one Exchange server needs to be configured in your onpremises organization if you want to configure a hybrid deployment. If you're running
Exchange 2013 or older, you need to install at least one server running the Mailbox
and Client Access roles. If you're running Exchange 2016 or newer, at least one
server running the Mailbox role needs to be installed. If needed, Exchange Edge
Transport servers can also be installed in a perimeter network and support secure
mail flow with Office 365.
Microsoft Office 365 The Office 365 service includes an Exchange Online
organization as a part of its subscription service. Organizations configuring a hybrid
deployment need to purchase a license for each mailbox that's migrated to or
created in the Exchange Online organization.
Hybrid Configuration wizard Exchange includes the Hybrid Configuration wizard
which provides you with a streamlined process to configure a hybrid deployment
between on-premises Exchange and Exchange Online organizations.
Azure AD authentication system The Azure Active Directory (AD) authentication
system is a free cloud-based service that acts as the trust broker between your onpremises Exchange 2016 organization and the Exchange Online organization. Onpremises organizations configuring a hybrid deployment must have a federation trust
with the Azure AD authentication system. The federation trust can either be created
manually as part of configuring federated sharing features between an on-premises
Exchange organization and other federated Exchange organizations or as part of
configuring a hybrid deployment with the Hybrid Configuration wizard. A federation
trust with the Azure AD authentication system for your Office 365 tenant is
automatically configured when you activate your Office 365 service account.
Azure Active Directory synchronization Azure AD synchronization uses Azure
AD Connect to replicate on-premises Active Directory information for mail-enabled
objects to the Office 365 organization to support the unified global address list (GAL)
and user authentication. Organizations configuring a hybrid deployment need to
deploy Azure AD Connect on a separate, on-premises server to synchronize your onpremises Active Directory with Office 365.

Move mailboxes between on-premises and

Exchange Online organizations in hybrid
deployments
With an Exchange-based hybrid deployment, you can choose to either move on-premises
Exchange mailboxes to the Exchange Online organization or move Exchange Online
mailboxes to the Exchange organization. When you move mailboxes between the onpremises and Exchange Online organizations, you use migration batches to perform the
remote mailbox move request. This approach allows you to move existing mailboxes instead
of creating new user mailboxes and importing user information. This approach is different
than migrating user mailboxes from an on-premises Exchange organization to Exchange
Online as part of a complete Exchange migration to the cloud. The mailbox moves discussed
in this topic are part of administrative Exchange management in a longer-term coexistence
relationship between on-premises Exchange and Exchange Online organizations.

Step 1: Create a migration endpoint

Prior to performing on-boarding and off-boarding remote move migrations in an Exchange
hybrid deployment, we recommend that you create Exchange remote migration endpoints.
The migration endpoint contains the connection settings for an on-premises Exchange
server that is running the MRS proxy service, which is required to perform remote move
migrations to and from Exchange Online.

Step 2: Enable the MRSProxy service

If the MRSProxy service isnt already enabled for your on premises Exchange 2013 Client
Access servers, follow these steps in the Exchange admin center (EAC):
1. Open the EAC, and then navigate to Servers > Virtual Directories.
2. Select the Client Access server, and then select the EWS virtual directory and
click Edit .
3. Select the MRS Proxy enabled check box, and then click Save.

Step 3: Use the EAC to move mailboxes

You can use the remote move migration wizard on the Office 365 tab in the EAC on an
Exchange server to either move existing user mailboxes in the on-premises organization to
the Exchange Online organization or to move Exchange Online mailboxes to the on-premises
organization. Choose one of the following procedures:

Move on-premises mailboxes to Exchange Online

You can use the remote move migration wizard on the Office 365 tab in the EAC on an
Exchange server to move existing user mailboxes in the on-premises organization to the
Exchange Online organization. Follow these steps:
1. Open the EAC, and then navigate to Office 365 > Recipients > Migration.
2. Click Add , and then select Migrate to Exchange Online.
3. On the Select a migration type page, select Remote move migration and then
click Next.
4. On the Select the users page, click Add
and select the on-premises users to
move to Office 365 and click Add and then click OK. Click Next.

5. On the Enter the Windows user account credential page, enter the on-premises
administrator account name in the On-premises administrator name text field
and enter the associated password for this account in the On-premises
administrator password text field. For example, corp\administrator and a
password. ClickNext.
6. On the Confirm the migration endpoint page, verify that the FDQN of your onpremises Exchange server is listed when the wizard confirms the migration endpoint.
For example, mail.contoso.com. Click Next.
7. On the Move configuration page, enter a name for the migration batch in the New
migration batch name text field. Use the down arrow to select the Target
delivery domain for the mailboxes that are migrating to Office 365. In most
hybrid deployments, this is the primary SMTP domain used for the Exchange Online
organization mailboxes. For example, contoso.mail.onmicrosoft.com. Verify that
the Move primary mailbox along with archive mailbox option is selected, and
then click Next.
8. On the Start the batch page, select at least one recipient to receive the batch
complete report. Verify that the Automatically start the batch option is selected,
and then select the Automatically complete the migration batch check box.
Click New.

Move Exchange Online mailboxes to the on-premises

organization
You can use the remote move migration wizard on the Office 365 tab in the EAC on an
Exchange server to move existing user mailboxes in the on-premises organization to the
Exchange Online organization:
1. Open the EAC and navigate to Office 365 > Recipients > migration.
2. Click Add , and then select Migrate from Exchange Online.
3. On the Select the users page, select Select the users that you want to
move and then click Next.
4. On the Select the users page, click Add
and then select the Exchange Online
users to move to the on-premises organization, click Add and then click OK.
ClickNext.
5. On the Confirm the migration endpoint page, verify that the FDQN of your onpremises Exchange server is listed when the wizard confirms the migration endpoint.
For example, mail.contoso.com. Click Next.
6. On the Move configuration page, enter a name for the migration batch in the New
migration batch name text field. Use the down arrow to select the Target
delivery domain for the mailboxes that are migrating to Office 365. In most
hybrid deployments, this is the primary SMTP domain used for both on-premises and
Exchange Online organization mailboxes. For example, contoso.com.
7. Choose whether to also move the archive mailbox for the selected user and enter the
database name youd like to move this mailbox to in the Target database text field.
For example, Mailbox Database 123456789. Click Next.
8. On the Start the batch page, select at least one recipient to receive the batch
complete report. Verify that Automatically start the batch is selected, and then
select the Automatically complete the migration batch check box. Click New.

Step 4: Remove completed migration batches

After your mailbox moves have completed, we recommend removing the completed
migration batches to minimize the likelihood of errors if the same users are moved again.
To remove a completed migration batch:
1. Open the EAC and navigate to Office 365 > Recipients > Migrations.
2. Click a completed migration batch, and then click Delete .
3. On the deletion warning confirmation dialog, click Yes.

Step 5: Re-enable offline access for Outlook on the

web

Offline access in Outlook on the web (formerly called Outlook Web App) lets users access
their mailbox when they're not connected to a network. If you migrate Exchange mailboxes
to Exchange Online, users have to reset the offline access setting in their browser to use
Outlook on the web offline.

How do you know this worked?

When you move existing user mailboxes between the on-premises and Exchange Online
organizations, the successful completion of the remote move wizard will be your first
indication that moving the mailbox will complete as expected.
Because the mailbox move process takes several minutes to complete, you can also verify
that the move is working correctly by opening the EAC and selecting Office
365 >Recipients > Migration to display the move status for the mailboxes selected in the
remote move wizard. The value of the Status is Syncing during the mailbox move, and
itsCompleted when the mailbox has successfully moved to either the on-premises or
Exchange Online organization.
After the mailbox move has completed, you can check that the remote mailbox located on
the on-premises or Exchange Online organization has been successfully moved by verifying
the mailbox properties. To do this, navigate to Recipients > Mailboxes in the EAC for
either the on-premises organization or Exchange Online organization. The user mailbox
should show a Mailbox Type of Office 365 for Exchange Online mailboxes and User for onpremises mailboxes.
You can also run the following cmdlet in the Exchange Management Shell to verify the status
of the migration batch.
Get-MigrationBatch -Identity <batch name>

Active Directory Federation Services (ADFS)

Active Directory Federation Services (ADFS) is a software component
developed by Microsoft that can be installed on Windows Server operating
systems to provide users with single sign-on access to systems and
applications located across organizational boundaries.

ADFS Server
Server that links to the credentials, and has the claims configuration as well as the
trusts. Generally not publicly accessible.

ADFS Proxy Server

Server that hosts the IIS instance that has the login pages for the websites requiring
authentication. Communicates back to the ADFS when requiring authentication.
Generally publicly accessible.

How To Install ADFS 2012 R2 For

Office 365
Whats new and improved in ADFS 2012
R2
The quick answer is a lot! Some examples include:

IIS dependency removed

Single server installation option removed and now have single farm install
(recommended to install a farm always in prior release anyway)

Separate ADFS proxy role removed. ADFS proxy now based off Web Application
Proxy (WAP), and is used to publish the ADFS server to the Internet. WAP can
publish many other applications, not just ADFS.

ADFS extranet lockout ADDS account lockout protection on the ADFS proxy

Access control based on network location to control user authentication to ADFS

Installing ADFS On Windows Server 2012

R2
After starting up server managers add roles and features wizard, select Active Directory
Federation Services, then click next.

We dont need to add any additional features. Remember that the IIS dependency was
removed in ADFS 2012 R2.

Clicking next takes us to the ADFS splash screen. Note that it helpfully tells us that the
specific ADFS proxy role has been removed in Windows 2012 R2 and how to go about
installing it. Shame I missed that the very first time I ran this, and could not find the
old school ADFS Proxy role

Clicking next will then install the necessary bits.

Bits are being shuffled around

Shuffling has been completed, and the installation is complete. You can launch the
ADFS configuration wizard from here, or alternatively if this window is closed it can be
launched from server manager.

Before starting the ADFS configuration wizard I already installed my 3rd party certificate
and tested that is was correctly installed.
Additionally a service account called ADFS-Service was also pre-created.
The wizard also states that you must have access to Domain Admin (DA) credentials!
Note that you are only given an option to either make a new ADFS farm or add this box
to an existing farm. This saves the painful issue from older ADFS builds, where ADFS
was not installed into a farm you were then unable to easily the add the second ADFS
server for redundancy.

Provide your domain admin credentials.

We need to select the SSL certificate that we will use and also provide the ADFS name
we selected in the design process.
In this case the name is adfs.tailspintoys.ca note that there is no concept of an
InternalURL or ExternalURL for the ADFS namespace. Clients will use the same name on
the intranet and internet to locate ADFS. Thus split DNS will make life simple!
Provide your chosen display name, and click next.

As mentioned earlier it is possible to use a GMSA as the ADFS service account. GMSA
will automatically update the service accounts credentials and administrators will also
be oblivious as to its password.
In this case a standard service account was used.

Select the database configuration as per the design.

The Tailspintoys corporation will use WID.

Review the options, and when happy pull the trigger!

For reference the PowerShell script is shown here:

#
# Windows PowerShell script for AD FS Deployment
#
Import-Module ADFS
# Get the credential used for the federation service account
$serviceAccountCredential = Get-Credential -Message "Enter the credential
for the Federation Service Account."
Install-AdfsFarm `
-CertificateThumbprint:"5804746A7980C8682FBF408D48EF6C3B02A5ZORG"
`
-FederationServiceDisplayName:"Tailspintoys STS" `
-FederationServiceName:"adfs.Tailspintoys.ca" `
-ServiceAccountCredential:$serviceAccountCredential

The ADFS pre-requisite checks are done, and we can proceed to the configuration:

One coffee later, we have a shiny new ADFS server whoo!!

What is the difference between ADFS and active directory

domain controller?
A Domain Controller holds that actual "Active Directory", the database of user & computers
which are members of the domain.
The ADFS -- Active Directory Federation Server -- doesn't not hold that database, but serves
as an intermediary from another/different external domain (or similar) then queries a
Domain Controller to request authentication for users trying to access that external domain.
An example would be a Office 365 deployment in the Microsoft Cloud (that is on the
Internet) might request the ADFS server to authenticate each user on the internal domain.
ADFS would pass this request to a domain controller and the answer back to the Office 365.

What is Directory Synchronization?

Directory Synchronization is the integration of your On-premises Active Directory
with an instance of Active Directory running in the Azure cloud. Synchronization
essentially makes a copy of the on-premises directory objects and then propagates
them to an Active Directory instance in the Azure cloud. After that, synchronization
runs on a scheduled basis to push changes from the on-premises directory to the
cloud instance. With few exceptions, synchronization only goes from on-premises to
the cloud. If one were to create a new user on the Azure Active Directory tenant,
that user would live only in the cloud and would never be propagated down to the
on-premises directory. This would create a Cloud (only) Identity (see below) which
would have its own login credentials and identity for Office 365 applications.

What is Federation?
Active Directory Federation Services (AD FS) can be used to provide
federation and single sign-on capabilities for end users who want to access
Office 365 applications. Windows Server 2012 R2 includes an AD FS role that
can function as an identity provider or as a federation provider. An identity
provider authenticates users to provide security tokens to applications that
trust AD FS (e.g. Office 365 applications). A federation provider consumes
tokens from other identity providers and then provides security tokens to
applications that trust AD FS.

Differences between Windows Server 2008, 2008 SP2 and 2008 R2

Windows Server 2008 and Windows Server 2008 SP2 are the same operating system, just at a
different service pack level (Windows Server 2008 started at the SP1 level because it was released
quite a bit after Windows Vista and SP1 ).
Windows Server 2008 R2 is the server release of Windows 7, so it's version 6.1 of the O.S.; it
introduces quite a lot of new features, because it's actually a new release of the system.
Windows Server 2008 R2 is includes key enhancements related to virtualization, management, IIS,
scalability and reliability, and Windows 7 integration
There are also differences at the GUI level, because WS2008R2 uses the same new GUI introduced
with Windows 7 (new taskbar, etc.).
Depending on what kind of applications you're developing, they may or may not encounter
problems on different O.S. releases; you should definitely check MSDN.
**Windows Server 2008 is the same codebase bits as Vista. It is available in two flavors 32 bit and

64 bit versions.
**Windows Server 2008 R2 is the same codebase bits as Windows 7 x64. It is only available in the
64 bit version.
In Simple terms..
Windows Vista SP1 = Windows Server 2008
Windows Vista SP2 = Windows Server 2008 SP2
Windows 7 = Windows Server 2008 R2

Windows Server 2008 is the same codebase bits as Vista. It is available in two flavors 32 bit
and 64 bit versions.

Windows Server 2008 R2 is the same codebase bits as Windows 7 x64. It is only available in
the 64 bit version.

Difference between windows server 2012 and R2

Windows server 2012 R2 brings many new features and enhancements to windows server
world compared to older version windows server 2012, will discuss major difference between
windows server 2012 and windows server 2012 R2 and some of the very innovative
Windows Server 2012 R2 Features and improvements.

Windows Server 2012 Schema version is 56 and Windows Server 2012 R2 is 69, schema
will be updated while doing Forest preparation/installing Windows Server 2012 R2

Active Directory comes first when I think about windows server, will start with Active Directory
new features on Windows Server 2012 R2

Difference between Windows Server 2008 and Windows Server

2008 R2
Windows Server
2008
It is based on kernal
version 6.0 ( the
same of Windows
Vista)

Windows Server 2008 R2

It is based on kernal version 6.1 ( the same of Windows 7)

It use the same GUI

introduced with
Windows Vista

It use the same new GUI introduced with Windows 7

Is for both 32 bit &

64-bit platforms

Is only for 64-bit platforms

Its Hyper V does not

have that feature

Hyper-V provides a dynamic, reliable, and scalable

virtualization platform combined with a single set of
integrated management tools to manage both physical
and virtual resources

It is only having Basic

Remote desktop
Services.

Microsoft RemoteFX, introduces a new set of remote userexperience capabilities that enable a media-rich user
environment for virtual and session-based desktops.

Normal Power
Management Service

Enhanced Power Management services which save up to

18 % more power than previous verison.

Normal Data
managemnet server

Enhanced Data Management server using File

ClassificationInfrastructure (FCI)

What is the main difference between windows server

2008/2008R2/2012/2012R2?
The main difference is Windows kernel version.

Windows Server 2008 uses NT 6.0 SP1 kernel, like Windows Vista SP1
Windows Server 2008 R2 uses NT 6.1 kernel, like Windows 7
Windows Server 2012 uses NT 6.2 kernel, like Windows 8
Windows Server 2012 R2 uses 6.3 kernel, like NT Windows 8.1

What is the difference between Windows Server

2008 R2 and Windows Server 2012?
A lot of functions were added in the newer Win Server OS, some examples below:
No more Std and Ent SKU, all Win Server 2012 SKUs are with functions like Ent SKU,
and Win Server 2008 R2 only supports Std functions.
Win Server 2008 R2 is without Hyper V, Win Server 2012 default supports Hyper V.

What is an MX record?
An MX record tells senders how to send email for your domain.
When your domain is registered, its assigned several DNS records, which enable it to be located on the
Internet. These include MX records, which direct the domains mail flow. Each MX record points to an
email server thats configured to process mail for that domain. Theres typically one record that points to a
primary server, then additional records that point to one or more backup servers. For users to send and
receive email, their domain's MX records must point to a server that can process their mail.
To filter email through the message security service, you must insert new records that point to the
message security service's servers.
For more about MX records, watch the video Understanding and Working with MX Records

Where are my MX records?

Your authoritative MX records are on your DNS provider's server. When you change the MX record on
your DNS provider, other servers will make copies of these updated MX records over time.

How can I see my MX records?

To check your current MX records, follow these steps:
1. Search for "MX lookup" on Google.com.
2. Select a search result from the list.
3. Type your domain name in to the field.
4. Select MX records if it's not the default search query.
5. Click Lookup.

How do I update my MX records?

If your company has its own DNS servers, talk to your DNS administrator. Otherwise, contact your domain
name provider.
For detailed instructions on how to update your MX records, see Change Your MX Records

Why should I update MX records?

For the message security service to work, we need you to route your mail to us. When you update your
MX records, we accept your mail, filter out the bad mail, and pass the good mail on to your server.

When should I update my MX records?

During activation, you'll receive a message telling you it's time to update your MX records.
If you're adding more domains later on, update your MX records after you've added the domain in the
Administration Console. Until your domain is set up in the Administration Console, mail will bounce if you
update your MX records.

What's the format of an MX record?

An MX record includes the following fields:
Name: The name of your domain.
Class: This is always set to IN, which stands for Internet.
Type: For MX records, this is always set to MX.
TTL: "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of
3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day
to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing
the MX records will take longer.
Preference or Priority: The order of preference for mail delivery. Sending servers should try the lowest
preference number first, then the next lowest, and so on.
Data: The host name of the mail server that handles mail for that domain.
For instance, if your domain is jumboinc.com, your MX records might look like this:
jumboinc.com. IN MX 86400 1 jumboinc.com.s7a1.psmtp.com.
jumboinc.com. IN MX 86400 2 jumboinc.com.s7a2.psmtp.com.
jumboinc.com. IN MX 86400 3 jumboinc.com.s7b1.psmtp.com.
jumboinc.com. IN MX 86400 4 jumboinc.com.s7b2.psmtp.com.

Every DNS host has a different user interface for MX records. Some use a trailing period and some don't.
Some allow you to set your TTL and some won't. Our instructions include information for most common
MX hosts, but yours may be different. If you're not sure what to enter, use the same format as your
existing MX records. Be sure that the message security service MX records have the first priority; the
exact numbers don't matter as long as the message security service MX records are the first. If your DNS
server allows fewer than 4 records, enter as many as you can.

For detailed instructions on how to update your MX records, see Change Your MX Records.

Why do I need four separate MX records?

We use redundant MX records as a backup in case any problem occurs. They give our network more
flexibility if any changes to architecture are necessary.

Should I update A records when routing mail to the message security service?
Do not update your A records. Since your MX records point to psmtp.com, you do not need to change any
A records.

Can I keep MX records pointed directly to my mail server as a backup?

Yes. If you want to keep a direct MX record for your mail server as a backup, you can, but be sure to
leave it at the lowest priority, after all four psmtp.com records. Leaving your own mail server in the MX
records should be a temporary backup measure, because spammers sometimes try to bypass the service
and connect directly to your mail server using your backup MX records. Once your mail is flowing through
the message security service successfully, consider changing your MX records to remove this backup.

How long do MX record updates take?

MX record updates are not immediate. After you've updated your MX records, it will take a while for every
sender to use the new MX records. Your original TTL setting determines how long (in seconds) this will
take. Changing the TTL setting won't speed this up.

Will I lose mail after changing MX records?

No. As long as you enter the MX records correctly, you won't lose any MX records. While your MX records
are changing over, some mail will be delivered using your old MX information, and some mail will be
delivered using your new MX information, but all of it will be delivered.

What happens if I type the wrong information into the MX record?

If you type the incorrect delivery information in the MX record, some mail will bounce. The sender will
receive a notice that the mail wasn't delivered. If this happens, correct the MX records as soon as
possible. Some mail may still bounce for a period of time (up to the length of the new TTL setting), but the
sooner you update the MX records to the correct setting, the fewer messages will bounce.

What happens when I update my MX records?

Once you update your MX records, mail will start flowing through the message security service. After your
old previous TTL (in seconds) has expired, all your mail flows through the message security service.
When your mail flows through the service, mail is bounced from IP addresses known to be a major source
of spam attacks or viruses. Also, if you have Non-Account Virus Blocking, mail to users will be filtered for
viruses as well. You'll get complete mail filtering after you've added your users.

How can I tell if the MX update worked?

Send a test message from an outside address, then view the full headers. The full headers are about 2050 lines of text. If the headers include the word "psmtp.com" then the mail flowed through the message
security service.

DNS Management: Record Types and

When To Use Them
A Records

A Records are the most basic type of DNS record and are used to point a
domain or subdomain to an IP address. Assigning a value to an A record is
as simple as providing your DNS management panel with an IP address to
where the domain or subdomain should point and a TTL.

A Record listing in the GoDaddy DNS Management Panel.

The screenshot above is a sample of A Record listings of different types.

You can see the use of the wildcard ( * ), @ symbols, and named host
name entries. Here, the primary naked domain record (@) and blog
subdomain point at the same IP address, but are separate records and
can be changed individually at any time. A Records are only able to take an
IP address as their value and you can point the same domain/subdomain
to multiple IP addresses by adding another A Record with the same name
but with a different IP address for the value.
You would want to use an A Record for your DNS entry if you have an IP
address that the domain/subdomain should point to or if you want to
establish a domain/subdomain to be used as the place to point a
CNAME. You can find out more about why you might want to do this in the
CNAME portion of this article.
CNAME

CNAME records are another commonly used type of DNS entry and are
used to point a host/name to another host/name.

CNAME record listing in the GoDaddy DNS Management Panel.

In the screenshot above, you can see immediately that one of the
important differences from A Records is that the value portion of the
record is required to be an existing subdomain/domain. You can see that

the journal host/name points to my blog.iamrobertv.com A Record,

which points to 198.101.164.57. What this means is that if I ever changed
the value of the blog subdomain, then the journal subdomain will also
inherently have its value changed.
As a host, we can use CNAMEs for customers as a means of being able to
change the IP address of a server or cluster of servers transparently and
without users having to make their own DNS adjustments. You can see an
example of this in the store host/name that points to a cluster of servers
of servers that sit behind the thor.openhostingservice.com subdomain.
Finally, you can see the use of the @ symbol to indicate that the www
host/name should point to the naked domain and use its value, which
when you see the A Record sample image above, points
to 198.101.164.57. This also means that if the value of the naked/primary
domain changes, the record of www will end up being affected
accordingly.
MX Record

Mail Exchanger (MX) records are used to help route email according the
domain owners preference. The MX record itself specifies which server(s)
to attempt to use to deliver mail to when this type of request is made to
the domain. They differ from A Records and CNAMEs in the way that they
also require a priority value as a part of their entry. The priority number
is used to indicate which of the servers listed as MX records it should
attempt to use first.

In the screenshot above, you can see that I am using two MX records that
have separate priority values and point to different subdomains. These
subdomains are pointed at two different email servers that are
designated to handle email. The MX record with the lower priority number
(0 in this case) is the first to be tried for email delivery. If this server is
unable to handle the mail request, the next lowest priority number is
used, which in this case would be 10.
Some email providers have only one MX record and some have well over
two. The number of MX entries you will need to create depends largely on
the mail provider and how they expect the load on these email servers to
be handled.
Youll notice the host name here is designated as the naked/primary form
( @ ). If you wanted to receive mail on a subdomain, you would adjust the
host/name accordingly and ensure your email provider is setup to handle
email from the subdomain.
TXT Record

A TXT record is used to store any text-based information that can be

grabbed when necessary. We most commonly see TXT records used to
hold SPF data and verify domain ownership.

TXT Record listing in the GoDaddy DNS Management Panel.

The screenshot above gives an example of how a TXT value would be
formed for both an SPF entry or a ownership verification for the
naked/primary host/name using the @ symbol. If you need to verify or
provide an SPF record for a specific subdomain, then you will need to use
the appropriate host/name in place of the @ symbol. The rule of thumb
for TXT records is that they require a an attribute name, follow by an
equals sign, followed by a value for the attribute. You can use this to relay
any sort of information youd like using a DNS record, so long as you have
a purpose for it and the record is properly formatted.
We wont go into the details of properly formed SPF records and what
their different pieces mean, but these will commonly be supplied to you
by the mail provider you are working with. In the same way, places that
require domain verification through use of a TXT record will also provide
you with a properly formatted TXT record value to use.
Sender Policy Framework

Sender Policy Framework (SPF) is a simple email-validation system

designed to detect email spoofing by providing a mechanism to allow
receiving mail exchangers to check that incoming mail from a domain
comes from a host authorized by that domain's administrators.

Create a Receive connector

to receive email from the
Internet
In most cases, you wont need to explicitly set up a Receive connector to receive
mail from the Internet, because a Receive connector to accept mail from the
Internet is implicitly created upon installation of Exchange.

Use the EAC to Create a Receive Connector to Receive

Messages from the Internet
1. In the EAC, navigate to Mail flow > Receive connectors. Click Add
Receive connector.

to create a

2. On the New receive connector page, specify a name for the Receive connector and
then select Frontend transport for the Role. Since you are receiving mail from the
Internet in this case, we recommend that you initially route mail to your Front End
server or servers, to simplify and consolidate your mail flow.
3. Choose Internet for the type. The Receive connector will receive mail from Internet
senders.
4. For the Network adapter bindings, observe that All available IPV4 is listed in
the IP addresses list and the Port is 25. (Simple Mail Transer Protocol (SMTP) uses
port 25.) This indicates that the connector listens for connections on all IP addresses
assigned to network adapters on the local server.
5. Click the Finish button to create your connector.
Once you have created the Receive connector, it appears in the Receive connector list.

Create a Send connector to

send mail to the Internet

Create the Send connector that's required to send mail to the Internet.
When install your first Exchange Server 2016 server, the server isn't able to send mail
outside of your Exchange organization. To send mail outside your Exchange organization,
you need to create a Send connector.

Create a Send connector to send mail to the Internet

Until you create a Send connector, mail can't flow from your Exchange to the Internet. The
exception is if you install an Edge Transport in your perimeter network and subscribe the
Edge Transport to your Exchange organization. For more information, see Edge Transport
servers.

Use the EAC to create an Internet Send connector

1. In the EAC, navigate to Mail flow > Send connectors, and then click Add
starts the New Send connector wizard.

. This

2. On the first page, enter the following information:

o

Name Enter a descriptive name for the Send connector, for example, To
Internet.

Type Select Internet.

When you are finished, click Next.

3. On the next page, verify that MX record associated with recipient domain is
selected. This means the connector uses DNS on the Internet to route mail, as
opposed to routing all outbound mail to a smart host. For information about creating
a Send connector that uses smart host routing, see Create a Send connector to route
outbound mail through a smart host.
When you are finished, click Next.
4. On the next page, enter the following information:
o

In the Address space section, click Add . In the Add domain dialog box
that appears, in Fully Qualified Domain Name (FQDN), enter an asterisk
(*), and then click Save. This value indicates that the Send connector applies
to messages addressed to all external domains.

The Scoped send connector setting is important if your organization has

Exchange servers installed in multiple Active Directory sites:

If you don't select Scoped send connector, the connector is usable

by all transport servers (Exchange 2016 Mailbox servers, Exchange
2013 Mailbox servers, and Exchange 2010 Hub Transport servers) in
the entire Active Directory forest. This is the default value.

If you select Scoped send connector, the connector is only usable by

other transport servers in the same Active Directory site.

When you are finished, click Next.

5. On the next page, in the Source server section, click Add . In the Select a
Server dialog box that appears, select one or more Mailbox servers that you want to
use to send mail to the Internet. If you have multiple Mailbox servers in your
environment, select the ones that can route mail to the Internet. If you have only one
Mailbox server, select that one. After you've selected at least one Mailbox server,
click Add, click OK, and then click Finish.
After you create the Send connector, it appears in the Send connector list.

Set up multi-factor authentication for Office

365 users
Applies To: Office 365 Admin

Summary: Learn how to set up Multi-Factor

Authentication (MFA) for Office 365 users.
MFA helps secure user sign-ins for cloud services
beyond just a single password. With MFA for Office
365, users are required to acknowledge a phone
call, text message, or app notification on their
smart phones after correctly entering their
passwords. They can sign in only after this second
authentication factor has been satisfied.
A form of multi-factor authentication is included
with Office 365, but you can also purchase Azure
Multi-Factor authentication that includes extended
functionality. For more information see feature
comparison of Azure Multi-Factor Authentication
versions.
To set up multi-factor authentication for Office 365
1.

Sign in to the Office 365 admin center.

2.

In the admin center, choose users and

groups > Active Users.

3.

In the classic admin center, next to Set Multifactor authentication requirements, choose Set up.

In the admin center preview, choose More > setup

azure multi-factor auth.

4.

Find the user or users that you want to enable

for MFA. In order to see all the users, you might
need to change the view at the top.
The views have the following values based on the
MFA state of the users:

Disabled
This is the default state for a new user not enrolled
in multi-factor authentication.

Enabled

The user has been enrolled in multi-factor

authentication, but has not completed the
registration process. They will be prompted to
complete the process the next time they sign in.
Enforced

The user may or may not have completed

registration. If they have completed the registration
process then they are using multi-factor
authentication. Otherwise, the user will be
prompted to completer the process at next sign-in
In non-browser apps (such as Outlook etc.) will
not work until app passwords are created and
entered into the non-browser apps.
5.

Check the check box next to the names you

chose.

6.

This will reveal two options on the

right: Enable and Manage user settings.
Choose Enable.

7.

In the dialog box that opens, choose enable

multi-factor auth.
To allow MFA users to create App Passwords for
Office client applications

1.

Multi-factor authentication is enabled per user.

This means that if a user has been enabled for
multi-factor authentication and they are attempting
to use non-browser clients, such as Outlook 2013
with Office 365, they will be unable to do so. An
app password allows this to occur. An app
password, is a password that is created within the
Azure portal that allows the user to by-pass the
multi-factor authentication and continue to use
their application.
IMPORTANT: All the Office 2013 client applications
support Multi-Factor Authentication through the use
of the Active Directory Authentication Library
(ADAL). This means that app passwords are not
required for Office 2013 clients.
Sign in to the Office 365 admin center.

2.

In the admin center, choose users and

groups > Active Users.

3.

In the classic admin center, Next to Set Multifactor authentication requirements, choose Set up.

In the admin center preview, choose More > Setup

azure multi-factor auth.

4.

On the multi-factor authentication page,

choose service settings.

5.

Under app passwords, choose Allow users to

create app passwords to sign into non-browser
applications.
This allows users to use client Office applications,
but they will have to enter a password of their
choosing first.

6.

Click Save, and then Close.

To manage user settings

1.

Find the user or users you want to manage and

select the checkbox next to their names.

2.

This will bring up two options on the

right, Enable and Manage user settings.
Choose Manage User settings. In the dialog select
one or more of Require selected users to provide
contact methods again, Delete all existing app
passwords generated by the selected users,
or Restore Multi-Factor Authentication on all
suspended devices. Make your selections and
choose Save.

Setting Up Domain Spoof Protection In Office 365

The following instructions will show you how to create a rule in Office 365 that will prevent your domain
from being spoofed from outside your environment.
This rule will accomplish the following;
1. Delete any inbound emails that originate from OUTSIDE your organization that are set to look like
they come from your domain. (domain spoof protection)
2. Allow emails from KnowBe4s servers to bypass this rule (so phishing tests can be conducted that
look like they are coming from internal email accounts).
Note: This rule will only protect your users from outsiders who are trying to spoof your domain. It will not
affect an external email from being sent using your domain to another email address (not to your
company). For simplicitys sake, it will prevent emails from being sent to your users from outside your
company that look like they are originating from within your company. But it will not prevent a person from
sending someone else outside your company an email that looks like it comes from your company. That is
typically handled with SPF record management which is not covered in this document.

Data Loss Prevention policies

To comply with business standards and industry regulations,
organizations need to protect sensitive information and prevent
its inadvertent disclosure. Examples of sensitive information that
you might want to prevent from leaking outside your organization

include financial data or personally identifiable information (PII)

such as credit card numbers, social security numbers, or health
records. With a data loss prevention (DLP) policy in the Office 365
Security & Compliance Center, you can identify, monitor, and
automatically protect sensitive information across Office 365.
With a DLP policy, you can:

Identify sensitive information across many locations, such as

SharePoint Online and OneDrive for Business.
For example, you can identify any document containing a credit
card number thats stored in any OneDrive for Business site, or you
can monitor just the OneDrive sites of specific people.
In addition, separately from the Security & Compliance Center, you
can also create a DLP policy in the Exchange Admin Center that
applies to email and other mailbox items. For more information,
see Data loss prevention in Exchange Online.

Prevent the accidental sharing of sensitive information.

Across all sites, you can identify any document containing a health
record thats shared with people outside your organization, and
then automatically block access to that document for everyone
except the primary site collection administrator, document owner,
and the person who last modified the content.

Monitor and protect sensitive information in the desktop

versions of Excel 2016, PowerPoint 2016, and Word 2016.
Just like in SharePoint Online and OneDrive for Business, these
Office 2016 desktop programs include the same capabilities to
identify sensitive information and apply DLP policies. DLP provides
continuous monitoring when people share content in these Office
2016 programs.

Help users learn how to stay compliant without interrupting

their workflow.
You can educate your users about DLP policies and help them
remain compliant without blocking their work. For example, if a
user tries to share a document containing sensitive information, a
DLP policy can both send them an email notification and show
them a policy tip in the context of the document library that allows
them to override the policy if they have a business justification.
The same policy tips also appear in Excel 2016, PowerPoint 2016,
and Word 2016.

View DLP reports showing content that matches your

organizations DLP policies.
To assess how your organization is complying with a DLP policy,
you can see how many matches each policy and rule has over
time.

What a DLP policy contains

A DLP policy contains a few basic things:

Where to protect the content locations such as SharePoint

Online and OneDrive for Business sites.

When and how to protect the content by

enforcing rules comprised of:

Conditions the content must match before the rule is

enforced -- for example, look only for content containing Social
Security numbers that have been shared with people outside your
organization.

Actions that you want the rule to take automatically

when content matching the conditions is found -- for example,
block access to the document and send both the user and
compliance officer an email notification.

How DLP policies work

DLP detects sensitive information by using deep
content analysis (not just a simple text scan).
This deep content analysis uses keyword
matches, dictionary matches, the evaluation of
regular expressions, internal functions, and
other methods to detect content that matches
your DLP policies. Potentially only a small
percentage of your data is considered sensitive.
A DLP policy can identify, monitor, and
automatically protect just that data, without
impeding or affecting people who work with the
rest of your content.

Policies are synced

After you create a DLP policy in the Security &
Compliance Center, its stored in a central policy
store, and then synced to the various content
sources, including:

OneDrive for Business sites

SharePoint Online sites

Office 2016 desktop programs (Excel 2016,

PowerPoint 2016, and Word 2016)
After the policys synced to the right locations, it
starts to evaluate content and enforce actions.

Policy evaluation in OneDrive for

Business and SharePoint Online sites
Across all of your SharePoint Online sites and
OneDrive for Business sites, documents are
constantly changing theyre continually being
created, edited, shared, and so on. This means
documents can conflict or become compliant
with a DLP policy at any time. For example, a
person can upload a document that contains no
sensitive information to their team site, but

later, a different person can edit the same

document and add sensitive information to it.
For this reason, DLP policies check documents
for policy matches frequently in the background.
You can think of this as asynchronous policy
evaluation.
Heres how it works. As people add or change
documents in their sites, the search engine
scans the content, so that you can search for it
later. While this is happening, the contents also
scanned for sensitive information and to check if
its shared. Any sensitive information thats
found is stored securely in the search index, so
that only the compliance team can access it, but
not typical users. Each DLP policy that youve
turned on runs in the background
(asynchronously), checking search frequently for
any content that matches a policy, and applying
actions to protect it from inadvertent leaks.

Policy evaluation in the Office 2016

desktop programs
Excel 2016, PowerPoint 2016, and Word 2016
include the same capability to identify sensitive
information and apply DLP policies as SharePoint
Online and OneDrive for Business. These Office
2016 programs sync their DLP policies directly
from the central policy store, and then
continuously evaluate the content against the
DLP policies when people work with documents
opened from a site thats included in a DLP
policy.
DLP policy evaluation in Office 2016 is designed
not to affect the performance of the programs or
the productivity of people working on content. If
theyre working on a large document, or the
users computer is busy, it might take a few
seconds for a policy tip to appear.

Permissions
Members of your compliance team who will
create DLP policies need permissions to the
Security & Compliance Center. By default, your

tenant admin will have access to this location

and can give compliance officers and other
people access to the Security & Compliance
Center, without giving them all of the
permissions of a tenant admin. To do this, we
recommend that you:
1.

Create a group in Office 365 and add compliance officers to it.

2.

Create a role group on the Permissions page of the Security &

Compliance Center.

3.

Add the Office 365 group to the role group.

What is DLP?
Data Loss Prevention is the capability to monitor potential data breaches inside your organization that
must comply with a set of policies. It allows a system to control and block sensitive information from
leaving an organization.
In Office 365, the platform helps you to identify, track and protect sensitive information in your
organization through deep content analysis and makes it easy to setup the policies. The DLP capability
applies to content in Exchange Online, SharePoint Online and OneDrive for Business services on Office
365.

How to use DLP in Office 365

In Office 365, the DLP capability is only available in the following subscription plans:

Enterprise E3

Enterprise E4

Government E3

Government E4

Nonprofit E3

Nonprofit E4

Setup of DLP policies

Administrators enable and manage this capability in the Admin portal of Office 365. In the Admin portal on
the left navigation (figure 1), go to Admin and then select Compliance.

Benefits of DLP
The DLP offerings in Office 365 let businesses quickly and easily comply with various industry or
government standards without making a big expensive investment. Which in the end puts you and your
organization in a much better place. It provides easier control over auditing information exchange inside
your organization. It will also keep the Security Officers more relaxed in your organization!
The DLP policies provide Policy Tips to your end users without affecting their productivity and allows
users to get educated into being compliant with organizational policies. There are more benefits to list
here, but you get the idea by now.

Identifying and Solving Active Directory Replication

Problems
How to resolve four common replication problems

Repadmin diagnoses Active Directory replication issues in Windows

Repadmin troubleshoots Active Directory replication issues, but it also

includes some commands that Windows administrators might not
recognize.
Repadmin has been a mainstay in the Windows toolbox since Windows 2000
was introduced, and its perhaps the most robust tool for troubleshooting
Active Directory replication issues, such as fixing lingering objects. As a staple
in Microsofts Windows Support Tools, Repadmin is available in many of the
more recent versions of Windows Server, including:

Windows 2000 -- located in Windows Support Tools on the server CD

Windows 2003 -- located in Windows Support Tools on the server CD,

but can also be downloaded with the Windows 2003 SP 2 Support Tools

Windows 2008, 2008 R2 --located in Remote Server Administration

Tools (RSAT)

Repadmin.exe can also be copied to a server instead of installing the

support tools.

As a command-line tool Repadmin is equipped with several operations that

Active Directory admins use on a regular basis. Here are some of the more
common options and how to use them:

/Showrepl --Shows the current replication status and error description

for each naming context that the domain controller (DC) is replicating and
can be run remotely to see the status of any DC. Using the /csv switch will
pipe the whole output into a CSV formatted table so errors can be seen on
a large number of DCs. Adding an asterisk (*) in the DCList parameter runs
the command on all DCs. For example:

Repadmin /showrepl * /csv > replication.txt

/ReplSum (Replication Summary) -- Provides an end-to-end summary

of inbound and outbound replication on every DC in the forest. Its handy
for getting a quick replication health check without wading through a lot of
data. For example:
Repadmin/replsum /bysrc /bydest /sort:delta

/regkey -- Configures the StrictReplicationConsistency registry key

to-strict (loose) or +strict (strict). All domain controllers should have this
key set to strict to protect against lingering objects. To set strict behavior on
all DCs, use the following command:
Repadmin /regkey * company.com +strict

/showobjmeta -- Dumps all the attributes for a given object. These

attributes show useful data, including when the object was created and on
which DC. Version numbers for attributes are also shown to help determine
if an attribute change has replicated. To track an object creation use the
following command:
C:\>repadmin /showobjmeta * "CN=HP-DC3,OU=Domain Controllers
OU, DC=company,DC=com"

In the output, there is a section for the command running on each DC. If
the attributes are listed, the object has been replicated. But if an error
occurs, such as DsReplicaGetInfo() failed with status 8333, then the object
has not yet been replicated to that DC.
Repadmin options you might not know about
Although Repadmin is a well-known tool for troubleshooting replication issues,
there are some commands that admins might not be as familiar with that can

assist with more complex problems between domain controllers in Active

Directory.

/replicate -- Replicates a domain controller to one or more DCs, and is

run as follows:
/ replicate <Dest_DC_LIST> <Source DC_NAME> <Naming Context>
[/force] [/async] [/full] [/addref] [/readonly]
The example below replicates the configuration naming context from WTetDC2 to Wtec-DC4. Note that the naming context is specified in
distinguished name (DN) format:
C:\Users\olseng>repadmin /replicate wtec-dc4 Wtec-dc2
cn=configuration,dc=wtec,dc=adapps,dc=hp,dc=com

Sync from Wtec-dc2 to wtec-dc4 completed successfully.

/showcert -- Checks whether the Domain Controller Certificate is stored

on the DC. Heres an example of how to use /showcert:
C:\Users\olseng>repadmin /showcert wtec-dc4

Checking for 'Domain Controller' certificate in store

'\\wtec-dc4\MY'...A Domain Controller Certificate was found
with Computer Object GUID .
Domain Controller Certificate V2 is present.

Expert help commands in Repadmin

Some of the more powerful Repadmin commands fall under the expert help
section and are designated for advanced users. To locate this tool
useRepadmin /experthelp.

For instance, /rebuildgc DCName is used to rebuild global catalogs (GC). It

essentially disables the GC partitions, builds temporary replication links to
each of the domain naming contexts in the forest and replicates them back. It
then cleans up all the temporary links and rebuilds the topology. On the
downside, this tool isnt timely and can cause a heavy network hit in a large
environment.
Another command that uses the expert help feature in Repadmin is: /add
<Naming Context> <Dest DC> <Source DC> [/asyncrep] [/syncdisable]
Its most useful when dcpromo doesnt work due to a replication failure. For
instance, if there is only one-way replication after using dcpromo, or if the
SYSVOL and NETLOGON shares dont show up after dcpromo reboots the
machine, this command can be used to build a low-level replication link.
However, the syntax isnt specified in the help feature, so admins must use the
DNS, CNAME as the argument in the DestDC and SourceDC arguments. Just
copy/paste from the DNS management snap-in for the respective servers and
enter the naming context in DN format.
Note: The good DC is listed as the destination DC (first on the command
list) and the bad DC (the one that wont replicate) is listed as the source
DC.
In the example below, dcpromo fails on the DC beginning with f3632fb7. The
other DC in the command is any other good DC (preferably in the same
site/subnet).
C:\Users\olseng>repadmin /add"dc=wtec,dc=adapps,dc=hp,dc=com" f303e249f90e-45f8-b165-1d5552013489._msdcs.wtec.adapps.hp.com f3632fb7-1baa-4034b765-d9b509fb36 e2._msdcs.wtec.adapps.hp.com

Remember, this command only works if something is broken. Executing it on a

perfectly good DC will produce an error message because a naming context
cannot be added to a DC where it already exists.
The options attribute is another handy tool in Repadmin.
Running Repadmin /options * lists the options set on all domain controllers in
an AD forest. A single DC can be specified as well by removing the asterisk
from the command. The syntax for the options attribute is as follows:
options [DC] [{+|-}IS_GC] [{+|-}DISABLE_INBOUND_REPL]
[{+|-}DISABLE_OUTBOUND_REPL] [{+|-}DISABLE_NTDSCONN_XLATE]
And the parameters within this attribute include:

IS_GC-- Indicates that the DC is a global catalog. Absence

of this option means it is not a GC.

DISABLE_INBOUND_REPL -- Disables inbound

replication.
DISABLE_OUTBOUND_REPL -- Disables outbound

replication.

DISABLE_NTDSCONN_XLATE -- Disables connections.

The following examples demonstrate different ways to use the options

attribute:
Repadmin /options -- Lists all options related to C:\Users\olseng>repadmin
/options wtec-dc2.

For example:

C:\Users\olseng>repadmin /options *

repadmin running command /options against server WTECDC4.Wtec.adapps.hp.com

Current DC Options: IS_GC

Repadmin /options +IS_GC -- Turns a DC into a global catalog. Likewise,

IS_GC turns a global catalog into a DC.
Note: Other options attributes disable inbound and outbound replication,
which are handy for troubleshooting or for doing an authoritative restore to
prevent premature replication. However, its important to track which options
are enabled to avoid any issues.
Repadmin/SiteOptions -- Lets admins see which settings are enabled. For
example, if an admin wants caching enabled they would use
[{+|-}IS_GROUP_CACHING_ENABLED].
Repadmin /RemoveLingeringObjects -- Removes lingering objects in forest
functional level domains in Windows 2003, 2008 and 2008 R2. Its also useful
for Active Directory disaster recovery and runs as follows:
/removelingeringobjects <Dest_DC_LIST> <Source DC
GUID>[/ADVISORY_MODE]
The Dest_DC_List is a list of domain controllers that might have lingering
objects. Note that you can insert GC for the DC list to operate on all GCs.
The Source DC GUID is the GUID of a DC that is considered good. If the
primary DC is free of lingering object errors it can be used. For example:
Repadmin /RemoveLingeringObjects GC: bf3bdb32-aed6-4a26-b6ce-107ae19c1a27
dc=emea,dc=company,dc=com

Remember, this command is not a fool-proof fix and doesnt always do the job.
For the best results, make sure the StrictReplication regkey is enabled on all
DCs to prevent lingering objects from returning. Its also important to run this
command on all naming contexts when working with multiple domain forests,
and keep checking for lingering object-related events in the event log to make
sure they are gone.
These are just some of the commands admins can use when working with
Repadmin and can be best learned by implementing them in a lab
environment. There are several other resources that discuss the ins and outs
of Repadmins as well. Start by reading the ExpertHelp files to learn several
other commands that were not covered here. Youll be glad you did.