How to put O365 mailbox on in-place hold using the Exchange Online powershell

In Exchange Server, In-Place Hold functionality is integrated with In-Place eDiscovery searches. You can use the In-Place eDiscovery & Hold wizard in the Exchange Administration Center (EAC) or the New-MailboxSearch and related cmdlets in Exchange Management Shell to place a mailbox on In-Place Hold.

Connect to Exchange online powershell and run the below command

New-MailboxSearch -Name “NameOfMailbox” -SourceMailboxes EmailAddress -ExcludeDuplicateMessages $True -InPlaceHoldEnabled $true -ItemHoldPeriod Number of Days -Description In-PlaceHoldDescription

 

Many organizations require that users be informed when they’re placed on hold. Additionally, when a mailbox is on hold, any retention policies applicable to the mailbox user don’t need to be suspended. Because messages continue to be deleted as expected, users may not notice they’re on hold. If your organization requires that users on hold be informed, you can add a notification message to the mailbox user’s Retention Comment property and use the RetentionUrl property to link to a web page for more information. Outlook 2010 and later displays the notification and URL in the backstage area. You must use the Shell to add and manage these properties for a mailbox.

Difference Between Azure AD Connect and Single Sign-On Options

Azure AD Connect offers customers a number of ways to enable a “Single Sign-On” (or SSO) experience for users. I think it is important to understand the differences in these options, so that when you deploy Azure AD Connect into customer environments, you can pick the right solution to suit the business needs.

Single Sign-On is an experience, wherein a single logon event (like logging into your local workstation) will automatically qualify you for login to other, disparate systems (e.g. Office 365)–in other words, you have all the tokens, exchanges and mechanisms in place that are needed just from your primary logon event. From the user’s perspective: after signing into the local Active Directory network on their workstation using a corporate email address, they might then open a web browser, point it at https://mail.office365.com, and automatically be signed into their Office 365 mailbox, without having to provide credentials a second time. This is (so to speak) a “true” SSO experience.

There are three primary methods we can use to achieve “true” SSO:

  1. Password Hash Synchronization with Seamless Single Sign-On enabled
  2. Pass-Through Authentication with Seamless Single Sign-On enabled
  3. Active Directory Federated Services

I am actually going to start with this last option, which was in fact, the original. Many early adopters of the 365 platform ended up with this type of configuration.

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Active Directory Federated Services (AD FS)

With AD FS, you need to deploy an on-premises service called Active Directory Federated Services, and it’s best if you make this service highly available. In this configuration, passwords never leave the on-premises Active Directory.  When someone attempts to sign-in to the Azure AD application, there is a configuration bit in the tenant that says “I’m not in charge of authentication, I have to go check in with <insert corporate AD FS web address here>.” This is super cool for security and compliance, because all authentication attempts are still logged against the local Active Directory.

But it is super uncool for many small businesses, because it requires setup and installation of AD FS, which also means that the cloud-based applications are dependent on the local Active Directory. So, if the corporate internet connection is down, so is your email. Wait a minute… why did we move our email to the cloud again? To prevent this scenario, our design would need to include:

  1. Properly configured AD FS infrastructure with SSL Certificates
  2. At least 2x AD FS web servers on separate links/ISP’s for HA
  3. Planned recovery from total loss of this site/infrastructure

Not a popular option for these reasons (complexity + dependency).

There are a couple of other considerations that might come into play. Most notably, the only solution here that supports the on-premises Multifactor Authentication Server is (unfortunately) AD FS. It is still possible to enable MFA for cloud-based applications using Azure AD MFA provider with the other options, but you do not have the ability to bring MFA to your network locally, without AD FS. Just something to be aware of.  On the flip side, it is worth noting that Azure Identity Protection (which requires additional licensing, e.g. P2) is not compatible with AD FS (because the authentication attempts must happen against Azure AD for Azure ID Protection reports to work).

Another consideration that applies only to PHS w/ SSO enabled: there may be a delay between, for example, disabling an account on-premises, and having that change updated in the cloud (because AAD Connect only synchronizes every 30 minutes by default). Furthermore, users who have passwords synchronized to Azure AD will technically have their cloud passwords set to never expire, and the password policies that apply on-premises will control when they need to update their password–but it is enforced on-premises only. Therefore it is possible, for example, to sign-in to cloud-based resources, even if the password on-premises has expired, because until the user changes the on-premises password, the old value will not be overwritten in the cloud.

There may be other small differences, but these are the noticeable ones that matter most to small businesses. I have summarized all of these points into this table for ease of reference:

Understanding Exchange 2010 server Roles

With Exchange Server Setup, you can deploy servers with specific roles through¬out the enterprise. Prior to setup and configuration, you need to decide how you will use Exchange Server 2010, what roles you will deploy, and where you will locate those roles. Afterward, you can plan for your deployment and then roll out Exchange Server.

Exchange Server 2010 implementations have three layers in their architecture: a network layer, a directory layer, and a messaging layer. The messaging layer is where you define and deploy the Exchange Server roles. The Exchange servers at the core of the messaging layer can operate in the following roles:

Mailbox Server This is a back-end server that hosts mailboxes, public folders, and related messaging data, such as address lists, resource scheduling, and meeting items. For high availability of mailbox databases, you can use database availability groups.

Client Access Server This is a middle-tier server that accepts connections to Exchange Server from a variety of clients. This server hosts the protocols used by all clients when checking messages. On the local network, Outlook MAPI clients are connected directly to the Client Access server to check mail. Remote users can check their mail over the Internet by using Outlook Anywhere, Outlook Web App, Exchange ActiveSync, POP3, or IMAP4.

Unified Messaging Server This is a middle-tier server that integrates a private branch exchange (PBX) system with Exchange Server 2010, allowing voice messages and faxes to be stored with e-mail in a user’s mailbox. Unified messaging supports call answering with automated greetings and message recording, fax receiving, and dial-in access. With dial-in access, users can use Outlook Voice Access to check voice mail, e-mail, and calendar informa¬tion; to review or dial contacts; and to configure preferences and personal options. Note that to receive faxes, you need an integrated solution from a Microsoft partner.

Hub Transport Server This is a mail routing server that handles mail flow, rout¬ing, and delivery within the Exchange organization. This server processes all mail that is sent inside the organization before it is delivered to a mailbox in the organization or routed to users outside the organization. Processing ensures that senders and recipients are resolved and filtered as appropriate, content is filtered and has its format converted if necessary, and attachments are screened. To meet any regulatory or organizational compliance require¬ments, the Hub Transport server can also record, or journal, messages and add disclaimers to them.

Edge Transport Server This serves as an additional mail routing server that routes mail into and out of the Exchange organization. This server is designed to be deployed in an organization’s perimeter network and is used to establish a secure boundary between the organization and the Internet. This server ac¬cepts mail coming into the organization from the Internet and from trusted servers in external organizations, processes the mail to protect against some types of spam messages and viruses, and routes all accepted messages to a Hub Transport server inside the organization.

These five roles are the building blocks of an Exchange organization. Note that you can combine all of the roles except for the Edge Transport server role on a single server. One of the most basic Exchange organizations you can create is one that includes a single Exchange server that provides the Mailbox server, Client Access server, and Hub Transport server roles. These three roles are the minimum required for routing and delivering messages to both local and remote messaging clients. For added security, you could deploy the Edge Transport server role in a perimeter network on one or more separate servers.

How to view current mailbox size, message count and last logon

You can use the Exchange Management Console to view who last logged on to a mailbox, the last logon date and time, the mailbox size, and the message count by completing these steps:

1. Expand the Recipient Configuration node and then select the Mailbox node.
2. Double-click the mailbox with which you want to work.
3. On the General tab, the Last Logged On By text box shows who last logged on to the mailbox, and the Modified entry shows the date and time the mailbox was last modified.
4. On the General tab, the Total Items and Size (KB) areas show the number of messages in the mailbox and the current mailbox size in kilobytes, respec¬tively.

If you want to view similar information for all mailboxes on a server, the easiest way is to use the Get-MailboxStatistics cmdlet. Here are some examples of using this cmdlet.

Get-MailboxStatistics -Server ‘corpsvr127’
Get-MailboxStatistics -Database ‘Engineering Primary’
Get-MailboxStatistics –Identity ‘cpandl\williams’

How to allow permissions on another user mailbox using powershell

Users need to access someone else’s mailbox, and in certain situations this is appropriate and preferable. You can grant permissions for a mailbox in two ways: grant access to a mailbox and its content or grant the right to send messages as the mailbox owner.

If you want to grant access to a mailbox and its contents but not grant Send As permissions, you can use the Manage Full Access Permission Wizard. In the Exchange Management Console, right-click the mailbox you want to work with and then select Manage Full Access Permission.

In the Manage Full Access Permission Wizard, click Add, and then use the Select User Or Group dialog box to choose the user or users who should have access to the mailbox. To revoke the authority to access the mailbox, select an existing user name in the Security Principal list box and then click Remove. Click Manage to set the desired access permissions.

In the Exchange Management Shell, you can use the Add-MailboxPermission and Remove-MailboxPermission cmdlets to manage full access permissions.

Adding full access permissions

Add-MailboxPermission -Identity UserWhoseMailboxIsBeingConfigured -User UserBeingGrantedPermission -AccessRights ‘FullAccess’


Add-MailboxPermission -Identity ‘Manager@hitechcandy.com’ -User ‘hiotechcandy\premr’ -AccessRights ‘FullAccess’


Removing full access permissions

Remove-MailboxPermission -Identity ‘UserBeingGrantedPermission’ -User ‘UserWhoseMailboxIsBeingConfigured’ -AccessRights ‘FullAccess’ -InheritanceType ‘All’


Remove-MailboxPermission -Identity ”Manager@hitechcandy.com’ -User ‘hiotechcandy\premr’ -AccessRights ‘FullAccess’ -InheritanceType ‘All’

If you want to grant Send As permissions, you can use the Manage Send As Permission Wizard. In the Exchange Management Console, right-click the mailbox you want to work with and then select Manage Send As Permission. In the Manage Send As Permission Wizard, click Add, and then use the Select Recipient dialog box to choose the user or users who should have this permission. To revoke this permission, select an existing user name in the Security Principal list box and then click Remove. Click Manage to set the desired Send As permissions.

In the Exchange Management Shell, you can use the Add-ADPermission and Remove-ADPermission cmdlets to manage Send As permissions.

Adding Send As permissions

Add-ADPermission -Identity UserBeingGrantedPermission -User UserWhoseMailboxIsBeingConfigured -ExtendedRights ‘Send-As’


Add-ADPermission -Identity ”Manager@hitechcandy.com’ -User ‘hiotechcandy\premr’ -ExtendedRights ‘Send-As’
or

Add-RecipientPermissions -identity ‘Manager@hitechcandy.com’ -Trustee ‘hiotechcandy\premr’ -AccessRights SendAs

Removing Send As permissions

Remove-ADPermission -Identity UserBeingRevokedPermission -User UserWhoseMailboxIsBeingConfigured -ExtendedRights ‘Send-As’ -InheritanceType ‘All’ -ChildObjectTypes $null -InheritedObjectType $null -Properties $null


Remove-ADPermission -Identity ”Manager@hitechcandy.com’ -User ‘hiotechcandy\premr’ -ExtendedRights ‘Send-As’ -InheritanceType ‘All’ -ChildObjectTypes $null -InheritedObjectTypes $null -Properties $null

How to hide mailbox from address book in exchange server 2010

you might want to hide a mailbox so that it doesn’t appear in the global address list or other address lists. One reason for doing this is if you have administrative mailboxes that you use only for special purposes.

To hide a mailbox from the address lists, follow these steps:

1. Open the Properties dialog box for the mailbox-enabled user account by double-clicking the user name in the Exchange Management Console.

2. On the General tab, select the Hide From Exchange Address Lists check box and then click OK.

How to Configure Auditing for exchange server

Auditing lets you track what’s happening with Exchange Server. You can collect information about logons and logoffs, permission use, and much more. Any time an action that you’ve configured for auditing occurs, it is written to the system’s security log, which you can access from Event Viewer.

You can audit Exchange activity by enabling auditing in a Group Policy object applied to your Exchange servers. This policy object can be a local Group Policy object or an Active Directory Group Policy object. You manage a server’s local Group Policy object using the Local Security Policy tool. You manage Active Directory Group Policy using the Group Policy Management Console (GPMC). GPMC is included as a Windows feature with Windows Vista and later versions of Windows. After you add GPMC as a feature, you can access it on the Administrative Tools menu.

You can enable Exchange auditing by completing the following steps:

1. Start the Group Policy Management Console by clicking Start, All Programs, Administrative Tools, Group Policy Management. You can now navigate through the forest and domains in the organization to view individual Group Policy objects.

2. To specifically audit users’ actions on Exchange Server, you should consider creating an organizational unit (OU) for Exchange servers and then define auditing policy for a Group Policy object applied to the OU. After you’ve created the OU or if you have an existing OU for Exchange servers, right-click the related policy object, and then select Edit to open the policy object for editing in Group Policy Management Editor.

3. You access the Audit Policy node by working your way down through the console tree. Expand Computer Configuration, Policies, Windows Settings, Security Settings, and Local Policies. Then select Audit Policy.

4. You should now see the following auditing options:

Audit Account Logon Events Tracks user account authentication during logon. Account logon events are generated on the authenticating computer when a user is authenticated.
Audit Account Management Tracks account management by means of Active Directory Users And Computers. Events are generated any time user, computer, or group accounts are created, modified, or deleted.
Audit Directory Service Access Tracks access to Active Directory. Events are generated any time users or computers access the directory.
Audit Logon Events Tracks local logon events for a server or workstation.
Audit Object Access Tracks system resource usage for mailboxes, information stores, and other types of objects.
Audit Policy Change Tracks changes to user rights, auditing, and trust relationships.
Audit Privilege Use Tracks the use of user rights and privileges, such as the right to create mailboxes.
Audit Process Tracking Tracks system processes and the resources they use.
Audit System Events Tracks system startup, shutdown, and restart, as well as actions that affect system security or the security log.

5. To configure an auditing policy, double-click or right-click its entry, and then select Properties. This opens a Properties dialog box for the policy.

6. Select the Define These Policy Settings check box, and then select the Success check box, the Failure check box, or both. Success logs successful events, such as successful logon attempts. Failure logs failed events, such as failed logon attempts.

7. Repeat steps 5 and 6 to enable other auditing policies. Note that the policy changes won’t be applied until the next time you start the Exchange server.

How to create a user account with a mailbox by using the New-Mailbox cmdlet in exchange 2010

Use below power shell in exchange shell to create a mailbox and account at the same time

New-Mailbox -Name “Prem Rana” -Alias “premr” -OrganizationalUnit “hitechcandy.com/People”
-Database “mbxDatabase1” -UserPrincipalName premr@hitechcandy.com -SamAccountName “shanek” -FirstName “Prem”
-Initials “P” -LastName “Rana” -ResetPasswordOnNextLogon $true

How to create new mailbox in exchange 2010 using management console

To create a User Mailbox, follow the below steps:

1. Open Exchange Management Console (EMC) and expand the Recipient Configuration node

2. clip_image002

3.

4. Right click on Mailbox and choose New Mailbox…

You can also create a new Mailbox by click on New Mailbox… from the right side pane under Actions

clip_image003

5. On the New Mailbox page, The available mailboxes are:

User Mailbox :
Select this button to create a mailbox that is owned by a user to send and receive e-mail messages. User mailboxes can’t be used for resource scheduling.

Room Mailbox :
Select this button to create a mailbox that will be used as a location resource for scheduling meetings. Room mailboxes can be included in meeting requests as resources and can be configured to automatically process incoming requests.
If you create a new user account for the room mailbox in Active Directory, it will be disabled. If you plan to associate the room mailbox with an existing account, you must select a disabled account.

Equipment Mailbox :
Select this button to create a mailbox that will be used as a resource for scheduling meetings. Equipment mailboxes can be included in meeting requests as resources and can be configured to automatically process incoming requests.

Linked Mailbox :
Select this button to create a user mailbox that is accessed by a user in a separate, trusted forest. You must still create a user account in the forest in which Exchange Server resides. This is required to create the necessary Active Directory object for storing the mailbox information.
Choose User Mailbox then click Next
clip_image005

6. On the User Type page, you can either create a new email for a new user or a new email for an existing user in Active Directory.
New User : Select this button to simultaneously create a new user in Active Directory and mail-enable the user.
Existing users : Select this button to mail-enable one or more existing users.
If you already have an Active Directory user wish to create for him/her a new email, then Select Existing User and then click Add to open the Select User dialog box. This dialog box displays a list of user accounts in the forest that aren’t mail-enabled or don’t have Exchange mailboxes. Select the user accounts you want to mail-enable, and then click OK to return to the wizard.
We will be creating a new user, so select New User and then click Next

clip_image007

7. On the User Information page, fill the user information and then click Next
If you want to create the user in a specific OU, then select the checkbox beside Specify the organization unit rather than using a default one and then click Browse, select the appropriate OU and click OK.
Fill User information and click Next
clip_image009

8. Type the Alias for your user mailbox, and then specify the mailbox database, retention policy, exchange ActiveSync mailbox policy and Address book policy ( if available )
I will be only selecting the mailbox database, as I didn’t create any policy yet.
To select a database, select Specify the mailbox database rather than using a database automatically selected, then click Browse
clip_image011
The available databases will be displayed. Select the mailbox database and then click OK
clip_image012
The selected database will be displayed, Click Next

clip_image014

9. Choose the Archive Settings.
You can have a local archive or a remote hosted archive for your user mailbox.
Items will be moved automatically from the primary user mailbox to the archive based on the retention settings.
clip_image016

10. Review the configuration settings and then click New
clip_image018

11. The wizard will be completed successfully. You can click on Finish to close the wizard.
clip_image020

12. Finally, you can see the new user created in the Mailbox node under Recipient Configuration
clip_image022