You can see exactly when we refuse the volume rename via a line like this in C:Program FilesUnideskUniserviceLogLog0.txt:
[06/11/2018][14:32:20:786] Log Detail Data Length 1 Offset 0x52764 SET_VOLUME_INFORMATION irp denied Status 0xae00
Note, however, we only intercept IRPs when our software is running. There are two circumstances where our drivers and software is not running: when you publish with Elastic Layering set to None, and when you edit an OS layer version. Editing the OS layer is just booting a modified clone of the original Gold VM’s boot disk. You edit that in place, finalize, and we copy the whole disk back. That way you can put things in the OS layer that might not play well without filter driver. You can relabel the C: drive on the OS layer, and you can do it in a published image with Elastic Layering off. Everywhere else, we’ll intercept the IRP and just deny it.
Now, in those circumstances, with our software not running, our software also doesn’t care if you relabel the disk. However, you should still not attempt to relabel the disk when editing the OS layer. It’s possible we would fail a Finalize operation on your modified OS layer – since we can’t find the right disk. But even if we allow you ti finalize that, it won’t change anything in the published image. The volume labels in the published image are set by the ELM, and you must not change them, even if you figure out a way. We use those volume labels to find our disks, and if you manage to modify the label on a published image, we will have problems with that.