Issue: Citrix/Roaming profiles are not used after RUM processing

Oct. 11th 2017

Description

Steps to recreate the problem:

  1. Citrix roaming profiles are in use.
  2. Roaming profile folders naming standard is “username.sourcedomain.v2”.
  3. Process profiles folder with a RUM processing task to add target permissions.
  4. When the migrated user logs onto the target domain a new roaming profile folder is created. This is not the expected behavior, the new profile name is in the format “username.targetdomain.v2”
  5. The target account does not use the processed roaming profile.

Resolution

The group policy setting that determines the location of the roaming profile folder needs to be changed:

  • Original configuration – with this group policy setting the roaming profile folder names are in the format username.domain.v2.
    • Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Session Host/Profiles
      • Set path for Remote Desktop Services Roaming User – Enabled
        • Profile Path – specify the path in the form \\Computername\Sharename
  • Updated configuration – with this group policy setting the roaming profile folder names are in the format username.v2.
    • Computer Configuration/Administrative Templates/System/User Profiles
      • Set Roaming profile path for all users logging onto this computer
        • \\Computername\Sharename\%USERNAME%
      • Copy all user profiles and permissions to the user profiles folder with the name username.v2 (removing the domain name).
      • Update group policy to use the %USERNAME% variable. Remove the original configuration from the GPO
      • Process the roaming profile and logon using the target account.  Using the new GPO setting will force the folder name to be “username.V2” and not to include the domain name.

The original configuration using the “Set path for Remote Desktop Services Roaming User” GPO setting includes the domain name in the roaming profile folder name, which caused the logon process to create a new folder with the target domain name. Updating the GPO to use the “Set Roaming profile path for all users logging onto this computer” removes the domain name from the folder name and allows the user to logon to the processed profile on the target domain.

Written by John Hobbs

Posted by LeadThem Consulting | in Authentication Services, Uncategorized | No Comments »

Issues when Migrating Exchange

Oct. 8th 2015

Error 2060 When Running Public Folders Sync Job

Environment:

Public folder Sync job is configured and running using legacy agents. During the sync, error 2060 “ImportPF Error 2060 Public store was not found on the current server” is showing up in the logs. Public Folders exist in the target and all the necessary rights are granted and working correctly.

Resolution:

This is a replication issue. Check whether the administrative mailbox specified for the public folder synchronization job is associated with public store on the same Exchange server. In this case, the Public Folder was homed to another server that did not have the Admin mailbox. Once this was changed, the Sync Job was able to find the PF database and import the contents from the source.

 

MaGE Native Move Error “Invalid situation the version of source or target side is not supported”

Environment:

Client is migrating from Exchange 2007 to 2007 with an Exchange 2010 CAS server in the target organization. During configuration of the MaGE agent the following error occurs in the console:

“Invalid situation the version of source or target side is not supported”

Resolution:

Documentation states that as long as there is a 2010 CAS server in the organization, Native Move can be used to migrate mailboxes. However, this is not entirely correct. Because the MaGE agent is using the native move PowerShell cmdlet in Exchange 2010, it expects the target mailboxes to reside on a 2010 database server. Since the mailboxes were being hosted on a 2007 server in the target, this was not possible. Legacy agents were then set up and configured and mailboxes were migrated without incident.

 

Mail Items Missing After Switch to Target

Environment:

Client users are stating that email is missing from their new target mailbox. Checked Mail Agent logs for any sync errors and attempted to perform a full resync of mailbox from Source to Target. Migration Manager Statistics and logged in comparisons of source to target show mailbox sizes to be the same.

Resolution:

While troubleshooting, it was revealed that 5 months earlier there had been a catastrophic failure of the source mail server and the server had been recovered through via recovery group. The OSTs had been preserved during this process and was found to contain the missing mail. Using a 3rd party utility to convert the backup OST to a PST, the client was able to import mail items to the new target mailbox.

 

Posted by LeadThem Consulting | in Migration Manager for Exchange | Comments Off on Issues when Migrating Exchange

QMM 8.9 Automation Error *FIX

Aug. 21st 2013

 

Here is the Fix for this error:

If you are encountering an error in the public folder sync for some of the PST files

“PowerShellCmdExec::Init  Error  440  Automation error”

QUEST Article 101427

https://support.quest.com/SolutionDetail.aspx?id=SOL101427&pr=Migration%20Manager%20for%20Exchange

This hotfix only applies to exchange agents MTA,MSA,CSA in order to fix public folder agents you must

  1. Apply The hotfix
  2. Stop all Quest Services on the box with the issue
  3. Reinstall MAPi CDO
  4. Run QMMExInstallAssemblies.bat in the QMM install directory
  5. Reboot QMM Box that has the issue

Article By: Wayne Thompson, Exchange Architect

 

 ———————————————————————————————————————————————————————————————-

 

 

 

Posted by LeadThem Consulting | in Quest Migration Manager | Comments Off on QMM 8.9 Automation Error *FIX