How to Migrate Users to CRM Online using SCRIBE? - dynamics-crm

Can you migrate system users prepared in staging database to CRM 2013 Online using SCRIBE?
I need to create 750 users (currently in CRM4) in CRM online and assign them to their source BUs. (Root BU excepted). I can stage them as required.
Can I migrate these users?

You cannot create users to a CRM Online using Scribe, you can only update them.
I have this issue recently and my solution was:
Create a DTS to create an CSV file* with the users: You can add the users using the Office portal or through the PowerSehll.
Creates a DTS with all the other information about the users (The CSV is pretty basic, so you will need to add all the other information related to every user).
Create a DTS with the relation between Users and Roles
*You can see the csv format in your Office portal, under Users->Active Users->Bulk add
https://portal.office.com/default.aspx##/UserManagement/ImportFile.aspx?refer=%2FEAdmin%2FUser%2FActiveUsers16.aspx
Maybe there is a quicker way to do it, but this was the approach I found.

Note that Scribe Insight isn't able to change a users business unit.
When I had a similar requirement (to update the business units of a large number of users) I uses SQL Server Integration Services.
Mike

Related

Microsoft Dynamics CRM, associated entities does not pull up records

We have a on-prem instance of Microsoft Dynamics CRM. The associated entities in all the forms come up blank and no records show up.
When I get this error in on-prem environments, it's usually because the database is getting pinged and queries to it are timing out. You may want to check the database to see if it is being overwhelmed and unable to return data.
we ended up updating the CRM version to resolve the issue.
temporary fix was implemented by restoring a backup of the database.

Is there a single database in case such as multiple organizations on a single on-premise CRM instance?

Sorry for asking this basic question. But I am not having on-premise Dynamics CRM instance, and so I cannot verify this from my end, and also I couldn't find this information online.
As On-premise deployment allows multi-tenant architecture, i.e., one instance can host multiple organizations. Does it mean that there will be one database for one organization? Or if there is a single database for all organizations?
I am more interested into learning about On-premise deployment, but I don't have resources to play around. So just thought to get this info in form of answers
Each organization in Dynamics CRM has its own database, and there is one server configuration database, with each CRM installation, called MSCRM_CONFIG.
Each organization is independent of the others. For example it can host different users and it can have totally different customizations.
One important thing that is to note (in my opinion), is that very frequently it may happen that you may need to move one organization to a different server, or create a copy of an organization on the same server. In this case, when moving to another server you only need the organization database, to copy and restore it to another server, and then import it through the Deployment manager. This will be sufficient and you do not need the MSCRM config database in this case, to have the same organization running on a separate server. This is of course you don't have advanced configuration on the database such as database mirroring, or load balancing.
See attached image, to see how databases look like in SQL Management studio, of Dynamics single server installation. Each database in red, ending with _MSCRM ia a separate organization, and the one in yellow (as its obvious), is the MSCRM_CONFIG database.
Multiple organizations mean multiple databases - one database per organization.
EDIT: plus one configuration database for all organizations

Scribe Insight: Migrate Principal Object Access table data from CRM 4.0 to CRM 2016

I am using scribe to migrate the Principal Object access data from CRM 4.0 to CRM 2016 DB.
The source adapter is a SQL Data Adapter which reads the data from the POA table in 4.0.
The destination adapter is the CRM Adapter and I have an insert step to insert the data into CRM 2016.
In the destination adapter, Scribe does not allow me to add the data links to PrincipalId and ObjectId fields from the source.
As far as I know, both of these fields are required to create a principal access object. However, since I can not create the data links, I do not know how I can copy this data over to CRM 2016.
Has anyone ever tried to Migrate the Principal Object Access table using scribe and have any suggestions for me to try out?
Any help will be greatly appreciated.
A few things I've noticed from your screenshot that might help you out:
You're trying to set the principalobjectaccessid on insert. I would think this is a no-no as you are creating a crm record and want a new guid to be assigned at that time instead.
You're doing the lookup to the type code but not to the foreign keys for the objectid and the principal id. You would need to refer to those (probably by name or an xref table as the guids will be different post import) in order to get the sharing in place.
In order to lookup those objects and principals you will need them to be entered into CRM2016 in a prior step.
One caveat I'd add is that based on the limited knowledge I have of you trying to move a 4.0 thought process involving sharing over to CRM 2016 this very well could be a bad idea. While sharing is still supported and certainly a part of the application there's performance issues that come up with extensive sharing and it's honestly a much more complex thing to work with then utilizing teams.. As I'm sure you're noticing now.
The POA table is internal to CRM and shouldn't be written to directly, even via the API.
It stores details of how records (determined by the objectid) are shared to users/teams (determined by principalid).
It sounds like you want to migrate your shares from CRM 4.0 to 2016. Scribe has a mechanism for doing this, using virtual fields. Look in the help for "Adapter for Microsoft Dynamics CRM" and search for "Granting Access". This explains how to use the virtual fields.

Dynamic CRM Online import data maintaining records ownership

I have a task to migrate Data from a CRM on premise data to a CRM online organization. I used two options, which are, migrated data using CRM import wizard and MSCRM Toolkit. But in both options, ownership of the records change to the user who migrated the data and the created on date is also got changed.
In my application, owners of the records are important because some of the filtered views are based on that information. Hence is there a better way(tool or process) to migrate the data maintaining the record ownership?
I would suggest to use SSIS Integration Toolkit from Kingswaysoft. Inside it you can map owners between old and new CRM. Also you can use overriddencreatedon field during import to override creation date of a record with actual value.

CRM Dynamics 2015: Conditionally updating a field in CRM using Scribe

We are using scribe to migrate data from a source into CRM 2015 Online. The DTS will run every 15 mins. Is it possible update the fields in the target based on a condition?
Currently I am following this approach:
IF(S1= UserVariables,#NULL!,S1 ).
Also “Allow NULL values to overwrite Target data” is unchecked. UserVariable is linked to that particular field.
The main reason for trying it this way is to stop the audit logs from building up in CRM if the source value is unchanged.(The client wants auditing ON for everything!). This is not working however. It is skipping the rows! No updates are performed even if the source value is different from target.
I tried IF(S1= "targetfield",#NULL!,S1 ), This time the updates are performing even if the source=target! Thus building up the audit logs.
Turning off auditing is not an option!
Is there any other way to do this?
Note: Using scribe insight v.7.7 on-premise.
I use CozyRock and Kingsway Soft mainly (Kingsway my personal pref), so I'm not 100% on the optimal approach for Scribe.
Anyhow, I normally write these to a staging table and then only update what will change. So if you:
Pulled records from the data source
Pulled corresponding records from CRM
Compared locally and built a staging table of only what will change
Finally update based on staging table records
This approach is typically faster and would not write unnecessary records to the audit log.

Resources