Storage Migration Service stuck at C$

Question

Hello everyone,

I've been trying to use the Storage Migration Service for the past few days, but I've run into a snag. The service seems unable to scan the C:\ drive. It just hangs indefinitely, whereas it scans the D:\ drive without any issues.

Here's what I've done so far:

• I'm using a domain account with the necessary privileges.
• I've installed all required services.
• All the necessary ports are open.

My goal is to migrate from a Windows Server 2012 to a Windows Server 2019 using an Orchestrator.

Has anyone else experienced similar behavior with the Storage Migration Service? Could this be a permissions issue? The servers were not initially set up by me but by the local admin, though I do have a domain admin account.

Any insights or suggestions would be appreciated!

Best regards,

Phillip

Answer 1

Hi,

Please check for errors in the event logs of the Storage Migration Service

• Application and Services Logs \ Microsoft \ Windows \ StorageMigrationService
• Application and Services Logs \ Microsoft \ Windows \ StorageMigrationService-Proxy

One possible cause is an error related to transferring files, which can be identified by examining the Storage Migration Service debug log. Another potential issue is the presence of unhandled Unicode characters in file names, which can be resolved by running a PowerShell script to locate and rename or remove the affected files.

https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/known-issues

Best Regards,

Ian Xue

---

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

If the Storage Migration Service is stuck, you can try the following steps:

1. Check event logs for errors.
2. Ensure network connectivity.
3. Verify sufficient permissions.
4. Restart the migration service.
5. Update to the latest version.
6. Consider using PowerShell commands for troubleshooting and resuming migrations.

Answer 3

I've already examined the logs, but I'm having trouble deciphering the error messages:

Here's an example of the error message:

The description for Event ID "10000" from source "Microsoft-Windows-StorageMigrationService-Proxy" could not be found. Either the component that triggers this event is not installed on the local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event was recorded on another computer, the display information had to be saved with the event.

The following information was included with the event:

11.13.2023-11:41:55.980 [Error] Unable to inventory directory \\C$\Documents and Settings\Default User\Local Settings\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\ ... this repeats like one hundred times.

So, i guess it has something to do with long File names or path?

Iam not sure how to use PowerShell so troubleshoot this problem. I can't finde a resource to use PowerShell to start a Storage Migration Service Job.

Best regards,

Phillip

Answer 4

Titel: Analyzing Storage Migration Service Issues with PowerShell Script

---

Hello everyone,

Initial Analysis:

Our initial approach involved analyzing two different log files from the Storage Migration Service. The first log suggested issues with a specific job ("Job does not exist"), indicating potential problems with job configuration or existence. The second log hinted at possible issues with recursive paths, which led us to suspect issues with symbolic links.

PowerShell Script for Further Analysis:

To dive deeper, we decided to utilize a PowerShell script to scan the C$ drive for symbolic links, particularly focusing on identifying any recursive links or links containing Unicode characters, which might be causing the hang-up. The script was written for PowerShell 4.0 and designed to traverse the file system, checking each directory and file for symbolic links, then reporting back any findings of recursive links or links with Unicode characters.

Here’s the final version of the script we used:

# Funktion zum Überprüfen von Symlinks
function Check-Symlink($Path) {
    try {
        $item = Get-Item -LiteralPath $Path -Force -ErrorAction Stop
        # Überprüfen, ob das Item ein Verzeichnis und ein Symlink ist
        if ($item -is [System.IO.DirectoryInfo] -and $item.Attributes -match 'ReparsePoint') {
            $target = Get-Item -LiteralPath $item.FullName -Force -ErrorAction Stop
            # Überprüfen auf rekursive Links und Unicode-Zeichen
            if ($target.LinkType -eq "SymbolicLink") {
                $linkTarget = $target.Target
                if ($linkTarget -like "*$item*") {
                    Write-Host "Möglicher rekursiver Link gefunden: $Path -> $linkTarget"
                }
                if ($linkTarget -match "[^\u0000-\u007F]") {
                    Write-Host "Link mit Unicode-Zeichen gefunden: $Path -> $linkTarget"
                }
            }
        }
    } catch {
        # Fehler ignorieren und fortfahren
        Write-Host "Fehler beim Zugriff auf: $Path"
    }
}
# Funktion zum Durchlaufen des Dateisystems
function Explore-Folder($Folder) {
    try {
        # Prüfen aller Items im Verzeichnis
        Get-ChildItem -LiteralPath $Folder -Force -Recurse -ErrorAction SilentlyContinue | ForEach-Object {
            Check-Symlink $_.FullName
        }
    } catch {
        # Fehler beim Durchlaufen des Verzeichnisses ignorieren
        Write-Host "Fehler beim Durchlaufen von: $Folder"
    }
}
# Starten des Scans auf dem Laufwerk C$
Explore-Folder "C:\"

Outcome:

The script ran successfully, providing feedback on the directories and files it was scanning. While it didn't find any recursive or Unicode-containing symbolic links, the process of systematically checking the file system was valuable. It helped us rule out one potential cause of the issue and guided us towards other areas that might need investigation.