Fix Microsoft iSCSI Initiator Service (MSiSCSI) Not Starting in Windows

What the MSiSCSI service does​

The service's short name is MSiSCSI. Its official description says it manages iSCSI sessions from a computer to remote iSCSI target devices, and if it is stopped, the computer cannot log on or access iSCSI targets. Also, if the service is disabled, any services that explicitly depend on it fail to start.

The detail that causes the most confusion is the default startup behaviour. Microsoft's Windows Server service guidance lists the startup type as Manual and marks the service "do not disable." The Microsoft Tech Community iSCSI cmdlet reference says the same thing: by default, this service is stopped and not set to start automatically.

So a stopped MSiSCSI on a PC that has never used iSCSI isn't a fault. It's the default. It only becomes a problem when you actually need to reach a target.

Summary: MSiSCSI is Manual by default. A stopped service matters only on machines that connect to iSCSI storage.

Step 1: Check the service and start it​

Guiding Tech starts in the Services console, which is the right place to begin.

1. Press Win + R, type services.msc and press Enter.
2. Find Microsoft iSCSI Initiator Service and note its Status and Startup Type.
3. Right-click it and choose Start.
4. If the machine needs iSCSI connections as soon as it boots, double-click the service, set Startup type to Automatic, then click Apply and OK.

Treat step 4 as a decision, not a reflex. Some guides tell you to switch to Automatic on every machine. TheWindowsClub's version of this fix says outright that if the service is disabled or set to manual, it will never start on its own, and it needs to be set to Automatic. That's too broad. On a workstation that never touches iSCSI, Manual is fine. On a server or VM that mounts persistent targets at boot, Automatic makes sense, and vendor documentation agrees. IBM's backup documentation, for example, says to ensure that the Microsoft iSCSI Initiator Service is started and is set to the automatic startup type on the system where the data is to be restored.

There's an easier route, too. According to Microsoft's Tech Community reference, if you open the iSCSI initiator control panel applet, it will prompt you to start this service and change the service startup type to Automatic. Search for "iSCSI Initiator" in the Start menu and accept the prompt. That handles both changes in one go.

Summary: Start the service. Set it to Automatic only if the machine needs iSCSI at boot. Opening the iSCSI Initiator applet offers to do both.

Step 2: Start it with PowerShell (and check the result)​

Guiding Tech's PowerShell step is correct. Open an elevated PowerShell window (type powershell in Run and press Ctrl + Shift + Enter), then run:

Start-Service -Name MSiSCSI

Microsoft's PowerShell documentation adds a few points the guide leaves out:

• You need elevation. By default, only members of the Administrators group can start or stop services, and even they must use an elevated PowerShell session.
• A Disabled service won't start. Start-Service works only on services set to Manual, Automatic or Automatic (Delayed Start). If you get "Cannot start service … on computer," check the startup type first.
• Success produces no output. Without -PassThru the cmdlet returns nothing, so confirm the result yourself.

Microsoft's Azure Elastic SAN setup guide for Windows clients uses this sequence:

# Check the current state
Get-Service -Name MSiSCSI

# Start it if stopped
Start-Service -Name MSiSCSI

# Only if the machine should start it at boot
Set-Service -Name MSiSCSI -StartupType Automatic

If Get-Service shows the service as Running afterwards, you're done with the service side. If the service was Disabled, change it to Manual or Automatic with Set-Service before starting it again.

"Force start" is a slightly generous name for what Start-Service does. It sends the same start request to the Service Control Manager that the Services console sends. If the console couldn't start the service, PowerShell usually can't either, but it will show you the error text, which helps with the next step.

Summary: Start-Service needs an elevated session, can't start a Disabled service and prints nothing on success. Always confirm with Get-Service.

Step 3: Check the Windows Event Log service​

If the service still won't start, Guiding Tech suggests checking the Windows Event Log service:

1. In Services, find Windows Event Log.
2. Make sure it's running and its startup type hasn't been disabled or changed.
3. If it has, double-click it, fix the startup type, then click Apply and OK.

This is a reasonable check. Microsoft's service guidance says of Event Log that stopping it may compromise system security and reliability, so a disabled Event Log service is a problem whatever iSCSI is doing.

Be careful about the claimed cause, though. TheWindowsClub goes further and states that if the Event Log is corrupted, stuck, or has broken permissions, MSiSCSI will fail with an Access Denied error. Neither guide cites Microsoft documentation showing that Event Log problems are a common cause of MSiSCSI startup failures, and the Microsoft material we reviewed doesn't establish it either. Check Event Log, but don't assume it's the culprit.

The Event Log does play one important role: it's where the failure gets recorded. Service-tracking sites note that if Microsoft iSCSI Initiator Service fails to start, the failure details will be recorded into Event Log. Open Event Viewer, go to Windows Logs > System, and read the actual error before you change anything else.

Summary: Make sure Windows Event Log is running. Then read the System log to find out why MSiSCSI failed rather than guessing.

Step 4: Registry permissions, for specific errors only​

This is Guiding Tech's riskiest step, and to its credit, the guide now says to change permissions only if an Event Log or service error points to them, and to back up the key first. The procedure is:

1. Press Win + R, type regedit and press Ctrl + Shift + Enter to run it as administrator.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\System.
3. Right-click the System key and choose Permissions.
4. Check the entry for the SYSTEM account. Don't change it unless an error shows SYSTEM can't write to the System event log.
5. Click OK.

Microsoft's documentation adds useful context. Access to the System log is controlled by a CustomSD value under that key, which uses Security Descriptor Definition Language (SDDL). By default, it gives Local System read, write and clear rights. Microsoft also notes that if CustomSD is set to an invalid value, the event log service logs an error when it starts and falls back to a default security descriptor. Microsoft now recommends managing log access through Group Policy (Computer Configuration > Administrative Templates > Windows Components > Event Log Service > System > Configure log access) rather than editing the registry by hand.

Every Microsoft registry procedure carries the same warning: back up before you edit. Export the key (File > Export in Registry Editor) before changing anything.

Summary: Treat registry changes as a targeted, backed-up repair when a logged error points to them, not a routine step. In managed environments, Group Policy may be setting these permissions, and a manual edit will just be overwritten.

Step 5: The service is running but the target won't connect​

This is really a separate problem, and Guiding Tech correctly separates it. If MSiSCSI is running but you still can't reach the target, the service isn't the issue. The network path is.

Guiding Tech suggests allowing TCP port 3260 in both inbound and outbound firewall rules. TheWindowsClub gives the same advice and notes that while the firewall usually does not stop the service from starting, incorrect rules can block iSCSI communication after the service launches.

That advice needs some limits:

• 3260 is the default, not a guarantee. In Microsoft's iSCSI connection API, the target portal's TCP port is a parameter you supply. Check which port your target actually listens on.
• Direction matters. An initiator makes outbound connections to the target, and the target accepts them inbound. Opening both directions on every machine is broader than you need. Open what your topology requires, within your organisation's firewall policy.
• Third-party security software counts. If an endpoint firewall other than Windows Defender Firewall is installed, check its rules as well.

Microsoft's Windows Server iSCSI troubleshooting guidance lists other causes of connection failures that restarting the service won't fix:

• MPIO misconfiguration
• NIC teams that aren't ready when iSCSI starts
• Mismatched VLAN, MTU or jumbo frame settings

To see what's actually connected, Microsoft recommends:

Get-IscsiConnection
Get-IscsiSession

If a stored target address is wrong, Microsoft's fix is to open iSCSI Initiator, remove the stale entry under Favorite Targets, and add it again with the correct details.

Summary: If the service runs but storage doesn't appear, check the target's address, port, authentication and network path. Don't keep restarting MSiSCSI.

A related boot-order problem: file shares on iSCSI volumes​

Here's a case neither consumer guide covers. On servers that share folders from iSCSI volumes, the problem can be when MSiSCSI starts, not whether it starts. HPE's integration guide explains that by default, the Server service starts before the iSCSI Initiator service, so after the Windows host reboots, file shares on iSCSI devices are no longer available.

Microsoft's fix is to make the Server service (LanmanServer) depend on MSiSCSI, using either sc config or the Services console's dependency settings. Be careful here: in general, sc config … depend= replaces a service's existing dependency list rather than adding to it. Check the current dependencies with sc qc LanmanServer first, and include them in the new list.

Quick reference​

The bottom line​

Most "iSCSI service not running" problems are simple. The service is set to Manual (which is the default) and nobody started it, or someone disabled it. Start it, confirm it with Get-Service, and set it to Automatic only on machines that need iSCSI at boot.

Guiding Tech's opening claim that the failure usually comes down to network permissions and configuration rather than hardware isn't backed by any Microsoft documentation we found. Before touching registry permissions, read the System log and work from the actual error. That's also the thing to post in a WindowsForum storage or Windows Server thread if you get stuck.