List Users' Shared Calendars

If you need to see a list of the URLs for a user's calendar that has been published for Internet access the specified calendar, you can use the following cmdlet:

Get-MailboxCalendarFolder “user”:\Calendar

This cmdlet, available in on-premises Exchange Server 2010, 2013 and Exchange Online, retrieves the publishing or sharing settings for a specified mailbox calendar. This information includes the calendar name, whether it is currently published or shared, the start and end range of calendar days published, the level of details published for the calendar, whether the published URL of the calendar can be searched on the web, and the published URL for the calendar.

 

Safe and Blocked Senders list in OWA 2013 and Office 365

It is very straightforward for end user to configure their Safe Senders and Blocked Senders list in OWA both for Exchange 2013 and in Exchange Online.

On the main page of OWA, select the gear icon at the top right of the page and select Options:

 

From the left hand pane of the Options panel, select block or allow:

 

In this page, users can add the desired sender(s) or domain(s) to the Safe Senders or Blocked Senders list by typing the e-mail address or domain name and selecting the add icon. Once all of the entries are added, scroll down to the bottom of the page and select save.

Netwrix Auditor Product Review

Netwrix is a US software company that specializes in auditing solutions for IT systems and applications. Its flagship product is Netwrix Auditor, previously known as Change Reporter Suite. Netwrix Auditor collects data on changes made to an IT infrastructure, such as Exchange, Active Directory, EMC storage, SharePoint, SQL, VMware and more. It generates reports showing the before and after values for who changed what, when and where in a human-readable format, with the possibility of long-term data archiving.

 

Netwrix Auditor is a great product that provides, in one place and in a readable format, all the auditing reports any Exchange administrator can want, something currently lacking out there. Its customizable capacities together with its reporting power, make this a great product for any type of organization where auditing is a must, from SMBs to Enterprises.

 

To continue reading, please check Netwrix Auditor Product Review at MSExchange.org.

 

 

How to obtain an Exchange Hybrid Edition product key

As a general description, Exchange Hybrid servers are used for hybrid deployment connectivity that seamlessly connects an on-premises Exchange and Exchange Online organizations.

 

To avoid the additional cost of an Exchange 2010 SP3 or Exchange 2013 server license for the hybrid server(s), organizations may qualify for a free Hybrid Edition product key. You can request a Hybrid Edition product key if all the following conditions apply:

• You have an existing, non-trial, Office 365 Enterprise subscription;
• You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization;
• You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key.

 

Note that Exchange 2013 includes native hybrid capabilities, so you can connect your Exchange 2013 organization to Exchange Online without a Hybrid Edition server. The Hybrid Edition is only for organizations running Exchange 2007 or 2010. Exchange 2010 customers can also continue to connect their organizations directly to Exchange Online without an additional Hybrid Edition server if they are updated to the latest Service Pack, or can choose to install an Exchange 2013 hybrid server. Exchange 2003 customers can continue to use Exchange 2010 Hybrid Edition servers to connect to Exchange Online with the latest Service Pack.

 

Up to this point, nothing new. However, while previously customers had to log a support case to request a hybrid key, this has now changed. To obtain a Hybrid Edition product key for your Exchange 2013 server or Exchange 2010 SP3 server, simply go to the Exchange hybrid product key distribution wizard.

Exchange Server 2013 SP1 Transport service stops and does not restart

When upgrading Exchange 20013 to Service Pack 1, if you have servers running both back-end and front-end roles and you run the front-end Microsoft Exchange Transport service on the server, you might experience the Microsoft Exchange Transport stopping and not restarting.

 

If you stop the Microsoft Exchange Transport service, you can start the front-end Microsoft Exchange Transport service. Then, when you try to start the Microsoft Exchange Transport service, that service does not start and the following events are logged in the Application log:

Source: MSExchangeTransport

Event ID: 1019

Task Category: SmtpReceive

Level: Error

Description: Failed to start listening (Error: 10048). Binding: 0.0.0.0:25.

Source: MSExchangeTransport

Event ID: 1018

Task Category: SmtpReceive

Level: Error

Description: The address is already in use. Binding: 0.0.0.0:25.

Source: MSExchangeTransport

Event ID: 1036

Task Category: SmtpReceive

Level: Error

Description: Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly.

Source: MSExchange Common

Event ID: 4999

Task Category: General

Level: Error

Description: Watson report about to be sent for process id: 19848, with parameters: E12IIS, c-RTL-AMD64, 15.00.0847.032, MSExchangeTransport, M.Exchange.Net, M.E.P.WorkerProcessManager.HandleWorkerExited, M.E.ProcessManager.WorkerProcessRequestedAbnormalTerminationException, 5e2b, 15.00.0847.030. ErrorReportingEnabled: False

Source: MSExchange TransportService

Event ID: 1046

Task Category: ProcessManager

Level: Warning

Description: Worker process with process ID 18420 requested the service to terminate with an unhandled exception.

This issue occurs if there is a receive connector of Transport type HubTransport that has the binding set to port 25 on the affected Exchange 2013 server. On an Exchange 2013 server that has both back-end and front-end roles, only the FrontendTransport server-type receive connector should have the binding set to port 25.

To fix this issue, run the following cmdlet to change the connector type from HubTransport to FrontendTransport:

Set-ReceiveConnector –Identity "Receive connector name" –TransportRole FrontendTransport

Alternatively, delete and re-create the receive connector and set its role to FrontendTransport.

Office 365 Multi-Factor Authentication

Microsoft has recently introduced Multi-Factor Authentication (MFA) for Office 365. This feature is now part of Office 365 Midsize Business, Enterprise plans, Academic plans, nonprofit plans and standalone Office 365 plans (including Exchange Online and SharePoint Online) at no additional cost.

 

MFA has actually been available for Office 365 administrative roles since June 2013, but it is now available to any Office 365 end user. There are also improvements to the capabilities available since last year, such as App Passwords for users so they can authenticate from Office desktop applications such as Outlook, Lync, Word, etc., as these do not yet natively support MFA.

 

MFA in Windows Azure and Office 365 provides several options for users as well as backup options in the event the user is not able to authenticate using their preferred method. These are:

• MFA apps are available for Windows Phone, Android and iOS devices. Users download the free app and activate it using a code provided during setup. When the user signs-in, a notification is pushed to the app on their mobile device and the user taps to approve or deny the authentication request. Once the app is installed it can operate in 2 different modes:

1. Notification: in this mode, the app prevents unauthorized access to accounts and stops fraudulent transactions. This is done using a push notification to the phone or registered device. The user checks the notification and if it is legitimate, he/she selects Verify. Otherwise, the user can chose to Cancel or even Cancel and Report Fraud if it is a fraudulent notification;
2. One-Time Password: in this mode, the Windows Azure MFA app is used as software token to generate an OATH passcode. This passcode is then entered along with the username and password to provide the second form of authentication.

• Automated phone calls can be placed by the MFA service to any phone, landline or mobile. The user simply answers the call and presses # on the phone keypad to complete their sign in;
• Text messages can be sent by the MFA service to any mobile phone. The text message contains a one-time six-digit passcode. The user is prompted to either reply to the text message with the passcode or enter the passcode into the sign in screen.

To continue reading, please check my Office 365 Multi-Factor Authentication article on MSExchange.org which explores MFA in Windows Azure Active Directory in general with a focus on MFA for Office 365.

 

Microsoft Exchange Web Services Managed API 2.2 Released

The Exchange Web Services (EWS) Managed API 2.2 provides a managed interface for developing client applications that use EWS. The EWS Managed API simplifies the implementation of applications that communicate with versions of Exchange starting with Exchange Server 2007 SP1. Built on the EWS SOAP protocol and Autodiscover, the EWS Managed API provides a .NET interface to EWS that is easy to learn, use, and maintain.

This release also includes the Exchange Server 2013 token validation library that we can use to build mail apps for Outlook that can be authenticated by the identity tokens issued by Exchange 2013.

You can download this latest release here.

Office 365 IMAP Migration From Different Domain

Office 365 IMAP Migration From Different Domain

Often I get asked if it is possible to perform an IMAP Migration from an e-mail system that is using a different domain than the one being used in Office 365. A typical scenario are those who want to migrate from Gmail (...@gmail.com) into Office 365, either using a custom domain or the Microsoft-provided one (...@domain.onmicrosoft.com).

Most of the times, the question comes to light when they try to perform exactly this but receive the following error message:

 

MigrationRecipientNotFoundException

Migration rate:

Error: MigrationRecipientNotFoundException: A recipient wasn‎'t found for ”user@gmail.com” on the target. Create a recipient of the appropriate type for this migration on the target and try again.

 

 

 

It is perfectly possible to use IMAP migration to migrate users who have different e-mail address suffix other than the domain which verified in Office 365!

The reason why we get this error, is simply because the CSV file used in the migration was not created properly. As a quick overview, the CSV file can contain up to 50,000 rows, one row for each user, and can be as large as 10MB. However, it is always a good idea to migrate users in smaller batches.

The required attributes for each user are as follows:

• EmailAddress specifies the e-mail address of the target mailbox in Exchange Online;
• UserName specifies the user logon name for the user's source mailbox on the IMAP server (in this example Gmail);
• Password is the password for the user's account in the IMAP messaging system.

The problem here is that sometimes administrators use the EmailAddress attribute to specify the e-mail address of the source mailbox, when it is actually used to match a source mailbox to its target mailbox. However, there is no need for a source e-mail address as no similar process to autodiscover is performed. Exchange will use the username and password specified, and try to connect to the source system using the connection settings for the migration batch:

 

 

As long as all these settings are correct, you should have no problems!