Guys, This might not be a BIS-F issue, but I’m running into a problem where the permissions on my write cache volume (MCS) seem to get corrupted. The image has been running fine for months, but now BIS-F fails due to permission issues. When this happens, the drive completely locks up— even owners and domain admins can’t edit or create files. The volume hosts event logs, WEM cache, etc. I’ve tried recreating a new volume, but the same issue happens after attempting to run BIS-F. Any ideas? Cheers

What changed? AV, sec solutions, gpo with permission alterations?

Hey James, its a new image in the process of rolling out in multiple batches. I cant think of any changes that would cause this, there have been a few standard upgrades for apps / patches. If I run BIS-F using a local admin it completes and the test machines function 'ok' but the redirections for event logs etc fail. I managed to reset permissions and take ownership and was able to create test files etc but after a reboot / rerunning Bis-f it fails due to perms and when I check manually I'm no longer able to create /amend files. I tried removing / readding from the domain and it works but dies again soon after. The boot / C drive seem totally healthy and don't have this issue. I'm going to attack it again in the morning with a fresh head and see if I can find anything, cheers

hrmmm sounds like something is resetting/altering/controlling those perms - somebody touched something

Yeah, very annoying. I'm also suspect my adm account is doing something weird. I did notice some odd errors in the event log around connectivity to the domain. I removed (again) cleaned up the AD com object, re-added and reviewed the reg. I removed a couple of profiles for my adm and a master ad/svc account that were appended with .bak. Once that was done, the WC perms looked ok and I was able to seal the image (with master/svc adm account - domain admin). I did noticed about 20 errors in the BIS-F log for 'device not ready' when clearing/resetting the logs, I'm not sure if that's an issue or the logs aren't enabled but i don't recall seeing that before. Trying to clear the logs in question manually I got the the same and they failed to enable, this is for things like Hyper-V admin so could be a non issue but unsettling nonetheless. Rolled the updated to the validation catalog and all looks to be working fine. I then booted the image and logged in with my adm and bang! Same perms issue with the WC... If I log in with the domain admin which I run BIS-f as it appears to be ok. I'm no wondering if there's something wrong with my named account and that causing the issues? Do you know if BIS-f needs to be, or should be run with a domain account? I don't recall having issues in the past if it was run with a local admin. The only other issue I have is that my FSLogix rules aren't pulling down from the central netlogon share. This has never worked during the build, its odd as the unc to netlogon is accessible on the VDAs that are provisioned and that's with me copy/pasting the rules share path from the reg on the VDA MCS provisioned machines. Might be an issue with the personalization task firing! Gaaaaaa, dont you miss this shit @James Kindon 😛

I miss it like a kick in the….foot. You can run bis-f with a local account without issue, I used to do it in automated build that never saw a domain during the build, obviously there are functionalities that will break if enabled and permissions are required (file copy etc)… Long and short is you broke stuff? :-p

Ok, managed to replicate without BIS-F even running so its not that 🙂 . I done a rough manual seal, shutdown & snapshot. Booted and had the same issue. I have noticed the C drive is encrypted with bitlocker and I'm almost certain that want the case before. The WC on the master is also dependent vs independent/persistent so I think something weird is going on with that in between versions. I'm disabling bitlocker and changing the disk type, lets see how we go.