Fix ERROR_WMI_READ_ONLY (0x00001075) – WMI Data Item Is Read-Only

Quick answer

Run the script with administrative privileges, then check if the property you're writing to is actually writable using Get-WmiObject -Class Win32_Service | Get-Member – most WMI classes expose only read-only properties by design.

What's ERROR_WMI_READ_ONLY (0x00001075)?

I've seen this error pop up most often when someone tries to set a property like Status or Caption on a Win32 class using VBScript or PowerShell. The error code 0x00001075 maps to WBEM_E_READ_ONLY – it's WMI's way of saying "you can't write to me."

This happens for a few reasons. The WMI provider that manages that class might only expose read-only views. Or you might be targeting a property that's computed, like TotalPhysicalMemory. I've also tripped over this when using Put_ on a class that inherits from a read-only base. The real trigger: you're trying to modify data that the provider controls, not your script.

Let me show you how to get around it.

Fix steps (numbered, most likely to work first)

1. Confirm the property is writable
   Open PowerShell as admin and run:
   

   Get-WmiObject -Class Win32_Service | Get-Member -MemberType Property

   
   Look for properties with set accessor. If it's missing, the property is read-only. You'll need a different approach.
2. Use the correct method
   Most WMI classes expose methods for changes. For example, instead of setting StartMode on Win32_Service, use ChangeStartMode().
   

   $service = Get-WmiObject -Class Win32_Service -Filter "Name='Spooler'"
   $service.ChangeStartMode('Automatic')

   
   This bypasses the read-only property entirely.
3. Run with the right security context
   If you're using Put_ and the provider supports it, but you still get 0x00001075, check your impersonation level. Add this to your connection:
   

   $connection = New-Object System.Management.ManagementScope('\\.\root\cimv2')
   $connection.Options.Impersonation = [System.Management.ImpersonationLevel]::Impersonate
   $connection.Connect()

   
   Without impersonation, the provider may refuse write access.

Alternative fixes if the main ones fail

Switch to CIM cmdlets

Sometimes PowerShell's WMI cmdlets have quirks. Try Set-CimInstance instead:

$instance = Get-CimInstance -ClassName Win32_Service -Filter "Name='Spooler'"
Set-CimInstance -InputObject $instance -Property @{StartMode='Automatic'}

Use a registry or file-based workaround

If the WMI class maps to a registry key or configuration file, write directly there. For example, service start types live in HKLM\SYSTEM\CurrentControlSet\Services\ServiceName\Start. But be careful – bypassing WMI can leave the system inconsistent.

Check for provider-specific documentation

I once spent two hours trying to write to a custom WMI class from HP's management tools. Turned out the provider required a special namespace and authentication flag. Check the vendor's docs or use Get-WmiObject -List to see if there's a separate writable subclass.

Prevention tip

Before you write any WMI script, query the class with Get-WmiObject -Class ClassName | Get-Member -MemberType Property | Where-Object {$_.IsWriteable}. This lists only writable properties. If none show up, the class is read-only for a reason – usually because the underlying data is controlled by the OS or hardware. Instead of fighting it, use the provider's built-in methods. Your future self will thank you.