EzCloudInfo

One of the user reported that the inbox folder was renamed to archive

There is one possibility of when the user has clicked on archive folder by accidentally by highlighted inbox – clicking on archive and then use create archive folder or choose existing folder.

while troubleshooting found this is a known issue and there is an article released from Microsoft

https://support.microsoft.com/en-us/help/2826855/folder-names-are-incorrect-or-displayed-in-an-incorrect-language-in-ou 

As per Microsoft this  can also occur if   a mobile device with different application like MDM  or a third-party server application synchronizes the Exchange Server mailbox.It could have been caused by a malfunctioning add-in.

If the default Inbox folder is changed unexpectedly to Archive we need to directly skip to step 4 and not look into step 1,2&3.

Use the step4  with MFCMapi tool to fix this problem.

Once the step4 is completed we need to run resetfolder as below

outlook.exe /resetfoldernames

After performing the step 4 we can run the below command and make sure the inbox folder in the root folder path is renamed correctly and not present as archive.

Get-MailboxFolderstatistics mbxname | select name,folderpath,foldersize,itemsinfolder

Thanks & Regards 

Sathish Veerapandian

We might get this error for few mailboxes during cross forest migration and the mailbox migration will not get completed for these mailboxes.

The archive GUIDs on source ‘Sathish Veerapandian’ and target ‘Sathish Veerapandian’ recipients don’t match. Source archive GUID: 00000000-0000-0000-0000-000000000000, target archive GUID:
71e7097b-5dc3-23a-c601-t84576k0ntlf.
+ CategoryInfo          : InvalidArgument: (SATHISH@exchangequery.com:MailboxOrMailUserIdParameter) [New-MoveRequest],
RecipientTaskException
+ FullyQualifiedErrorId : [Server=MSEXCH1,RequestId=c1b6f3aa-6138-420b-8deb-6149f349fc43,TimeStamp=8/2/2017 4:54:
28 PM] [FailureCategory=Cmdlet-RecipientTaskException] 5802C9B0,Microsoft.Exchange.Management.Migration.MailboxRep
lication.MoveRequest.NewMoveRequest
+ PSComputerName        : MSEXCH1.exchangequery.com

Reason:

Initially the mailbox in the source forest had an exchange archive enabled. When the migration started the all the emails have been moved to the primary mailbox and the archive was disabled for the users.

The ADMT was used initially to  migrate the user accounts in bulk for user properties , mail attributes ,prepare move request was run and while running new move request got the above message for few users.

If we see the ADMT logs the users mailbox msexchArchiveguid properties were migrated when the ADMT was run in the bulk job migration initially.

Later since these mailboxes on the source the archive mailbox was  removed , the MRSproxy while initiating the mailbox moves from the source identifies this archive guid value on source to be null and target having a older value which was copied by ADMT and gives the error.

We can verify the mailbox archive GUID from source and target by

Get-Mailbox MBXName | fl *archive*

Solution:

Take  all the mailboxes which was failed with this value, prepare a csv file and rerun the ADMT only for them , prepare move request and then run the New move request

This will successfully migrate these mailboxes.

If we have only less number of users handful of them we can simply go to the target user account and clear the old value msexcharchiveguid from the Attribute editor from Active Directory users and Computers.

After this ADMT rerun job is done rerunning the newmoverequest will move all the failed mailboxes.

Thanks & Regards
Sathish Veerapandian

In this article we will have a look at option to integrate the Cisco Jabber with outlook to save the conversation history in outlook folder.

We can enable the Jabber client to automatically save chat histories in Outlook like same how we have conversation history folder option in Skype for Business.
Here after the integration we can see a folder called Cisco Jabber Chats.

Below are the steps:

1)  Set the EnableSaveChatHistoryToExchange parameter to true in the jabber-config.xml file.

The default value after the installation is set to false in the config file. Having this value to false will not save the conversation history in Outlook.

Steps to update the conversation history in the Jabber-config.xml file:
a) Login to the CUCM TFTP server and access the below URL

http://:6970/jabber-config.xml

After accessing this URL jabber-config.xml  will be downloaded.
b) Update the xml file with EnableSaveChatHistoryToExchange true as below

Once this is completed we need to upload the updated file with the same name on each of the TFTP server present in the Cluster.
Post this operation restart the TFTP service on each TFTP server for the update to reflect immediately.

2) There is option to specify the authentication settings.

Authenticate Using Single Sign On for the Operating System:
When we set this the jabber client will use the account details of the logged in user to authenticate with exchange server.It users NTLM authentication method. This method will be easier.

Update the jabber-config.xml file with ExchangeAuthenticateWithSystemAccount parameter to true.

Authenticate by Syncing Credentials:
We can sync the Exchange credentials with another set of credentials for users which will be the jabber client credentials. With this method, the client will be using the credentials to authenticate to the Exchange server.

Below parameter needs to be updated to sync credentials in Jabber.xml config file

In this example Cisco UCS is defined as the service which provides the Exchange server with credentials for authentication.

If we don’t specify an authentication method, then users can authenticate directly from the Outlook tab in the Options menu of their clients. But this will be manual process where the server name needs to be entered and not automatic server discovery.

3) Specify Server Addresses

After we set the EnableSaveChatHistoryToExchange value to true and decide on the authentication method we need to select an option for the jabber client to reach the exchange server address.
Jabber client uses the Exchange autodiscover for this integration.

So for this configuration to make it happen automatic we can configure the autodiscover domain parameter in the jabber-config.xml file.

Access the jabber-config.xml file same as step 1 through TFTP server, configure the ExchangeAutodiscoverDomain parameter.
Define the Autodiscover domain URL’s.

The Jabber client will use defined autodiscover URL in the config file to search for the Exchange server at one of the following Web addresses:
https:///autodiscover/autodiscover.svc
https://autodiscover.domain.com /autodiscover/autodiscover.svc

This option can be checked in File – Options – Outlook in Cisco Jabber Client
Server settings and user settings can be checked from here.

There is an option to  change the chat history preference from the user side as below

The local jabber-config.xml file will be stored in the below location of end users PC
C:\Users\%user-profile name%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config

Also we can see the server configuration through the client having the cached TFTP file in the below location

userprofile\appdata\roaming\cisco\unifiedcomms\jabber\CSF\config\cache

Once all the above configuration are completed we can see a folder called Cisco Jabber Chats created in the Outlook and the Cisco Jabber Conversation histories.

Thanks & Regards
Sathish Veerapandian

Assume below scenario:

Performing the mailbox move Pull  migration request from the target. The MRS proxy is enabled on the source forest.

The MRS proxy  core component of the move requests is responsible for migration.

After initiating the bulk move pull request from target we can check the below things on Exchange 2016  on the target Mailbox Server

Open Resource Monitor – Select Network – and Select MSExchangeMailboxReplication
If we notice we can see the send B/Sec and ReceiveB/Sec for the MRS service.exe will be increasing

Monitoring this for a while after initiating bulk moves will give us an average idea of how much transfer rates we are getting on our target Exchange servers.We can also run the below command  for one large move request mailbox to analyze he transfer rate

Get-MoverequestStatistics  -Identity  “currentlymovingmbxname” | fl mrsservername,remotehostname,requestqueue,bytestransferredperminute,starttimestamp,lastupdatetimestamp

After getting the MRS server name we can go to that server and monitor the transfer rate for msexchangemailboxreplication.exe for few minutes.This will gives us an idea of how much transfer bytes per second we are getting for the move requests.

Also we can see the remote connections – To which IP it is connecting to for pulling the mailboxes from the source

We can see them on the TCP connections under network – Remote Address and in the local address we can see our Exchange server

We can see the remote TCP connections by using the below cmd from command prompt from the target Exchange 2016 Mailbox Server

netstat -ano | findstr remoteCASIP

Note :

It’s very important to note that when we see the remote connections we should see the local IP of the CAS (remotehostname) and not its public routable IP.
If it’s not resolving in local IP better to put source cas servers local IP as host entry in target  Exchange Servers.
This will work because there will be IP communication on port 443 set in place already for the cross forest to work.
If the connections are going through local IP’S then the move requests will be faster.

We can run the below command to see if the MRSServer in the target is distributed among all of them which will speed up the migration process.

Get-Moverequest  | Get-MoverequestStatistics  | fl mrsservername,remotehostname,requestqueue,bytestransferredperminute,starttimestamp,lastupdatetimestamp 

We can get the network utilization report from the firewall which is allocated for this migration. We can get this from the time when the migration was started and time it got completed.

It’s always better to have a dedicated bandwidth for cross forest migration (separate VPN tunnel) temporarily till the migration is completed.

There is one amazing complete move requests status  script provided by Microsoft product team.

https://blogs.technet.microsoft.com/exchange/2014/03/24/mailbox-migration-performance-analysis/

This works well for Cross forest on premise Exchange migration environments also.But make sure the Step 1 is exactly run as below with including the 1 dot with  space before running the script only  then it works.

. .\AnalyzeMoveRequestStats.ps1

Thanks & Regards
Sathish Veerapandian Continue reading →

Recently in one of the Exchange Server was frequently giving this alert on the SCOM alerts.

Ran the below command to check the health of the affected Exchange Server

Get-ServerHealth -Server ServerName

Could see the MailboxMigration HealthSet Unhealthy and the other healthsets were healthy.

The SCOM alert too reported the same DUMP directory:

<b>Dump Directory:</b>
C:\Program Files\Microsoft\Exchange Server\V15\Diagnostics\MigrationResponderDumps
at Microsoft.Exchange.Monitoring.ActiveMonitoring.Migration.Probes.MRSQueueScanProbe.DoWork(CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Execute()
— End of stack trace from previous location where exception was thrown —

Also at the end provided the same information for troubleshooting

Note: Data may be stale. To get current data, run: Get-ServerHealth

As a part of normal troubleshoot restarted the Mailbox replication service and the issue still persists.

Now started looking into the event logs and got the below event

It was trying to process jobs in a recovery database which was created by an admin and forgot to remove them after a restore job.

So dismounted this recovery database and removed them which solved this issue and after that this error never reappeared again.

Thanks & Regards

Sathish Veerapandian

This article explains on integrating Cisco Telepresence Suite with Exchange Server 2016. Before that lets have a brief on these components.

Cisco Telepresence Management Suite (Core Component of Video Collaboration):

This component in the Cisco IPT infrastructure provides the on-premises video collaboration.By this component we would be able to configure, Deploy, manage ,schedule , analyze and track the telepresence utilization  within an organization.

Cisco TMS helps in the following:

1) Helps Admins in the daily operations, configuration and maintainence of the telepresence network.
2) Helps consumers to use these telepresence network according to their customization.Like telepresence deployment as a service Example : Setting up meeting rooms of multi-monitors, multi-microphones and multi-channel speaker systems which gives stunning real like audio,video experience.
3) Helps in monitoring the Telepresence utilization and analyzing them.

What is Cisco TelePresence Management Suite Extension for Microsoft Exchange ?

Cisco TelePresence Management Suite Extension for Microsoft Exchange (Cisco TMSXE) is an extension for Cisco TelePresence Management Suite that enables videoconference scheduling via Microsoft Outlook, and replicates Cisco TMS conferences to Outlook room calendars.

Cisco TelePresence Management Suite Extension for Microsoft Exchange (Cisco TMSXE) is one of their extension for Cisco TelePresence Management Suite.

How it helps us in Scheduling the Meeting :

1)By having this it enables the option to Video Conferencing Scheduling via Microsoft Outlook.
2)Replicates Cisco TMS conferences settings to Outlook Room Calendars.
3)Makes end users to book Audio/Video conferences based on the Meeting room Availability from Outlook.

Cisco TMSXE Installation:

This Cisco TMSXE server runs on Windows server Cisco TMSXE component will be installed on this server along with booking service option chosen.
It similarly uses the IIS as web server. Enable https on the Default Website after the installation.

All the other configurations in Cisco components required for this integration like integrating with CUCM , CMS must be configured on the Cisco TMSXE and Cisco TMS server. There are more configurations on the TMS and TMSXE componenets which needs to be performed before integrating with Exchange Server.

In a small deployment the Cisco TMS and its extensions can be co-located on the same server.
In large scale deployments Cisco TMSXE extensions is seperate and remote SQL instance is required. And seperate Cisco TMS and Cisco TMSPE are always co-resident.

DNS Requirements:

The Cisco TMSXE server must be present on the same server VLAN where we have AD,Exchange servers.
The communication will be authenticated using the Cisco TMSXE Exchange service user account.

EWS and Autodiscover must be reachable from the TMS and TMSXE server for them to function.

Licensing:

Each telepresence endpoints to be booked through Cisco TMSXE must be licensed for general Cisco TMS usage.

In our case from Exchange perspective only the Meeting rooms where we need telepresence to be enabled must have the license.

Supported Exchange Server Versions:

1. Office 365 ( Active Directory Federation Services and the Windows Azure Active Directory Sync tool are required)
2. Exchange Server 2016 CU1  (latest CU’s preferred)
3. Exchange Server 2013 SP1  (latest CU’s preferred)
4. Exchange Server 2010 Sp3  (Latest Roll-ups preferred)
5. Exchange Server 2007   (Latest Roll-ups preferred)

Exchange Requirements:

1. TMSXE purely depends upon Exchange  AutoDiscover and EWS components to show the configured resource mailboxes availability
2. Room Mailboxes added to Cisco TMSXE must have below configurations

a)Delete the subject
b)Add the organizer’s name to the subject
c)Remove the private flag on an accepted meeting

3.Cisco TMSXE Service Account with Mailbox is required.This service account will be used in Cisco TMS to connect to Exchange, Cisco TMSXE and Cisco TMS.

Enable impersonation for the service user in Exchange to prevent throttling issues.

To enable impersonation run the below command:
New-ManagementRoleAssignment –Name:impersonationAssignmentName – Role:ApplicationImpersonation –User:[ServiceUser]

Certificate Requirements:

Https is the default communication protocol for communicating with Cisco TMS and with Exchange Web Services.

Certificate can be issued from a Trusted CA , since this is only server to server communcation between the Exchange CAS services (EWS/AutoDiscover) and TMSXE services no public SSL is required.

So the TMSXE server certificate issued from Trusted CA should have the below:

1. Should have the host name of the TMSXE server.
2. Should have the host name of the Exchange servers for the EWS and Autodiscover services in secure communication.

To verify that we have certificates that are valid and working:
1. Launch Internet Explorer on the Cisco TMSXE server.
2. Enter the URL for the Exchange CAS and verify that the URL field turns green.
3. Enter the URL for the Cisco TMS server and verify that the URL field turns green.

Below will be the Work Flow :

1. End User Books a meeting through Outlook addin.
2. Exchange Checks the resource Mailboxes availability and books the meeting and sends initial confirmation.
3. Cisco TMSXE communicates with Exchange and passes them on to Cisco TMS.
4. Cisco TMS checks system and WebEx availability and attempt to book routing resources for the telepresence.

Additional Tips:

1. The Cisco TMS is dependent only on resource calendars which are configured for this Telepresence feature.
2. Cisco TMSXE does not have permissions to modify the calendars of personal mailboxes.
3. All the other configurations  required for this integration must be configured on the Cisco TMSXE and Cisco TMS server.

Thanks & Regards
Sathish Veerapandian

During an Exchange CU update we were getting the below message

Prior to this all the  Exchange servers were fully patched including  the latest .net assemblies since it was CU5 upgrade.

If we look into the task manager we can see this process running and consuming large CPU resources. This is a .net related process that does the compilation job based on the priorities it is having high priority assemblies  and low priority assemblies.

What is MSCORSVW.exe?

The .Net framework has technology  called Native Image Generator Technology (NGEN) which will speed up the process for .net apps which will run only on a periodic basis purely to improve the performance of that machine

This process MSCORSVW.exe is used by NGEN  to improve the startup performance of .NET apps. So probably after an windows update especially .net patch if we have we can see this process running only at that time and consuming more CPU.

Solution for this problem:

1. Solution 1: We can wait for a while for this .net compilation job to complete probably 5 or 10 minutes time. Once completed if we rerun the setup  things will  go fine.
2. Solution 2: By default, NGEN only uses one CPU core for this operation . There is an option to make this work done quickly by making it to use up to 6 cores when we require them. By doing this it will complete its compilation job quickly.

Open CMD in elevated mode and run this command from this path

c:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executeQueuedItems

Running the above will  Execute queued compilation jobs with extra CPU cores and make it faster.Now wait for the process to precompile all the assemblies, after a couple of minutes it will be completed.

There will be ngen log as well generated in the same location where we executed this command which we can have a look at after the job completes.

References:

https://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx
https://blogs.msdn.microsoft.com/dotnet/2013/08/06/wondering-why-mscorsvw-exe-has-high-cpu-usage-you-can-speed-it-up/

Thanks & Regards
Sathish Veerapandian