I'm having this issue and wondering if it's a BUG:

Using powershell on the VMM 2012 server, Legacy custom properties (Custom1-Custom10) cannot be updated. Try this and see:

get-vm | select name,{$_.customproperties[9]}
get-vm | Set-VM -custom10 "TEST10"  | Select Name
get-vm | select name,{$_.customproperties[9]}

What I find is that custom9 hasnt changed for all VMs. sometimes it changes for none of them... :(

I can set other fields (like -TAG) just fine...

yes I'm admin and running elevated powershell.

I'd appreciate it if someone can verify these symptoms on their systems.

cheers,

-MCT

That script should work in theory. If you look in your job history, does it record a Set-VM job for every VM? Are the jobs missing, or are they marked as failed? If so, they should have a reason for the failure recorded.

The potential logic problem with your script is if you've added or changed custom property fields to certain HostGroups. If -Custom10 doesn't match CustomProperties[9] in the VM return (because you've defined or changed other custom properties), you won't see the property get set on those VMs.

Basically my question is: What is failing? Is the job not starting, or the job failing, or is the job succeeding but your script isn't showing the resulting custom property like you'd expect?

Hope this helps

Cheers, Hilton

Many thanks for the quick reply :)

These commands are typed directly into an elevated powershell window, so there is no scheduled job as such.

Looking at the job log in scvmm shows that a "change properties" job succeeded for each VM, but the change tracking tab only shows that the "state" changed from "stopped" to "stopped" (I.E. it didn't change)

What happens is that there are no errors, all the commands return expected lists of names of VMs but the custom property simply doesn't get set.  No errors in the event logs of course.

HTH,

-MCT

Interestingly, if I set the custom1..custom10 fields using the GUI it works, this problem seems limited to powershell.

• Edited by MCTitsreallymethistime Wednesday, October 16, 2013 8:52 AM

More diagnostic information:

If I use powershell to set the custom field to blank, that works. Then the next time I can set it to any value and that works too. However if I try to change the value (from one non-blank value to another non-blank value) then (whilst watching the scvmm screen in the background) I see the new value briefly appear then immediately revert to the old value.

What it looks like is that when the vmm code was changed (from 2008R2) to add "custom" custom fields (custom fields of any value), something was broken in the the handling of these "legacy" (fixed name) custom fields.

-MCT

You're absolutely right - very interesting! I will make sure a bug gets opened on this behavior.

Custom properties were changed fairly radically in 2012 to allow a lot more extensibility. Each custom property is an object in its own right, with relationships to any number of VMM objects. The 10 predefined custom properties were left for backwards compatibility, and it appears that the Set-VM -Custom10 interface has a bug that only allows it to work if no property was previous defined.

The new way to set custom properties is this:

$cp10 = Get-SCCustomProperty -Name Custom10
Get-VM | % {Set-SCCustomPropertyValue -CustomProperty $cp10 -Value "TEST2" -InputObject $_}

That will iterate through each VM, and change the custom property called "Custom10" associated with this VM. I've verified, and this method works correctly on SCVMM 2012 R2. It should also work on 2012 and 2012 SP1.

Hope this helps

Cheers, Hilton

I'm glad to hear that the issue is a bug and it's not just me going crazy :)

many thanks again - much appreciated.

-MCT

P.S. Would you be able to update this thread when/if a hotfix becomes available please?

Just wondered if there had been any progress on this bug at all?

many thanks,

-M

Time passes...

There really is no point in posting questions here is there...?