Aaron

My feedback

  1. 144 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Aaron supported this idea  · 
  2. 101 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Aaron commented  · 

    Frankly, I'm very surprised at the Admin response of "it doesn’t fit in the current narrative of ShareGate Desktop". I would consider addressing Sharegate Desktop migration failures as one of the top priorities, exceeded only by more reliable initial migrations.

    We routinely encounter issues with migrations. Some may not copy because of a timeout or throttling issue. Some may incorrectly report access denied, but work successfully on subsequent attempts. There may be some errors that will require changing specific settings to address the issue. However, the bulk of the errors can be addressed by re-migrating the failed content in Normal mode with Overwrite specified. Without Overwrite, another incremental may not address the problem, since the time stamp of a partial copy will likely be the same as the source, or a newer timestamp from when the copy was performed.

    To handle these errors, I've resorted to the following, mostly using PowerShell. I programmatically export all of my migration logs as CSV files. I programmatically filter the exported log files, to look for specific Error and Warning event types, and dump that subset of events into other files (FileErrors, SiteErrors, and OtherErrors). I manually review the CSV files to identify rows where fields like Warnings, Errors, or Details have exceeded reasonable limits and wrap for hundreds of lines (It would be great if export results were cleaner as well). I clean up that wrapped data for better readability. I re-migrate SiteErrors using the same scripts that were used for the initial site migration. I have a different set of scripts to re-migrate files that threw errors. There will also be some errors from re-migrating FileErrors that may require changes like limiting versions, but the number of errors that require manual intervention is significantly reduced. The OtherErrors are errors that need further review and may require manual migration. I have also used processes for handling Folder errors as well, but more often than not, I’ve found those to be reported inaccurately as a part of poor OneNote migration support. Of course, the errors which need to be addressed depends on which version of Sharegate you are running, and what has been changed in that version.

    Using custom scripts and complicated processes on my end to handle Shargate shortcomings is less than ideal. Changes made in Sharegate application development can/will adversely affect my processes, which is why the Sharegate Desktop is the ideal location to be addressing the issues. If content migration reliability can’t be increased, than ease of addressing errors is of the upmost importance.

  3. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  4. 119 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Hello everyone,

    I hope everybody is safe. I just wanted to update you regarding this upcoming feature.

    I’m happy to tell you we are a few weeks away from releasing it. In the meantime, here’s a mock-up/prototype of the feature so you can take a look at what’s coming:

    https://cn3680.axshare.com/#id=p1n0zh&p=copy_screen&dp=0&sc=2

    The UI and Wording is still a work in progress, but you can still have a good idea of what it will be.

    Note that to advance to the Destination screen, you’ll have to select all the teams from the source tenant

    Feel free to send me your comments and feedback.

    Cheers,

    Aaron supported this idea  · 
  5. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  6. 6 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  7. 18 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

  8. 140 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Since the default is now disabled. It should prevent most situation some of you are describing.

    We still feel like the Auto-Assign as site collection administrator is a useful option in certain case.

    If you encounter an issue you can always refer to this documentation to fix it. https://support-desktop.sharegate.com/hc/en-us/articles/115000647528-Can-I-remove-myself-as-an-administrator-after-I-have-auto-assigned-myself-as-one-

    An error occurred while saving the comment
    Aaron commented  · 

    This should really be changed. I can thing of multiple things that could be done to make this better. Rather than setting this globally, it should be set per tenant/connection, or even per web app. I am typically connected to several tenants, and I don't want site collection admin access auto-applied everywhere. Furthermore, it would be ideal to be able to specify the account, or better yet - the group that we want to automatically grant site collection admin access. More often than not, more than one user performs these administrative tasks. I would rather grant site collection admin access to a group with a professional looking name than a bunch of individual user accounts.
    Feedback sent from the OneDriveInfo view.

    Aaron supported this idea  · 

Feedback and Knowledge Base