User Layer Repair Utility with network file share three layers deep

[Jordan Barnartt]

Hello,

 

I've been trying to configure the User Layer Repair Utility to work with our environment.  I was having issues where the script was able to obtain the OS layer, app layers, and user information, but It wasn't able to find the user layer sizes.  We utilize Nutanix Files as the file share for App Layering, and unfortunately it doesn't support having files directly in the root directory of the share.  Due to the location of the JSON files, it means we need to have our App Layering information three layers deep: \\server\folder1\AppLayeringFolder.

 

It doesn't seem as though the Utility accounts for this scenario.  Looking at the GetUserLayers.ps1 script, Line 67 and Line 71 identify certain folders by their depth from the start of the path.  I tried increasing these by 1, but still ran into issues and I imagine it's still related.  When I select which user layers to find the size for, the script runs and chooses different user layers than the one I selected, and I'm not exactly sure of the reason for this.

 

Is there any chance of having the utility updated to meet the needs of this use case, or are we out of luck?

 

Thank you,

 

Jordan

[Rob Zylowski]

Jordan if you download the latest version it should fix your issue.  Thanks for letting me know it didnt work.

[Rob Zylowski]

Hi Jordan what version are you using?  I changed the code to use just -recurse rather than the -Depth because older versions of powershell didnt support the depth command.  So first try with the latest version which is 2.2.  Let me know what you find.  I did have someone who uses Nutanix test this latest version for me and it worked for him.  But if its still not working after you try with 2.2 we will figure it out.

 

Rob

 

[Jordan Barnartt]

Hi Rob,

 

Thanks for the prompt response.  I am using version 2.2 of the program.  Using the program as it comes, with none of the changes I noted above made, I do experience issues.

 

The repair tool is able to get the OS layer and repair files okay.  The expand tool is able to get the OS layers, but when it tries to get the user layers, it fails.  If I click the Get User Layers button, it says:

 

Running getUserLayers.ps1...

Checking User Layers for OS Layer ID [Our OS layer ID #]

 

The heading row of the table is generated, but nothing is listed under it.  Looking at getUserLayers.ps1, I think at least some part of the issue lies with how the $arrParentFolder (line 67) and $ParentFolder (line 71) variables are assigned.  They are assigned to $arrFolderNamep[6] and $arrFolderNamep[5] respectively.  $arrFolderName is a list of the full file path split along the backslash character.  These variable assignments assume that the App Layering share is only 2 folders deep (\\server\AppLayeringFiles), whereas ours is 3 layers deep (\\server\share\AppLayeringFiles).

 

Cheers,

 

Jordan

[Rob Zylowski]

Hey Jordan is that is the case you should just be able to change the indices to match your layout.  so instead of $arrFolderNamep[6] and $arrFolderNamep[5] use $arrFolderNamep[7] and $arrFolderNamep[6].  I just tested and that works for me.  I will create a new version that figures out those numbers from the path in setup but for now try that.

 

Also make sure in setup you put the three levels in your path.  For example i tested with \\zdc2\unidesk\test

[Jordan Barnartt]

Wow, you move fast, Rob!

 

Unfortunately, I'm still running into issues although they are different from last time.  I'm able to get the OS layers, but when I try to get the repair files or user layers, it fails.  The errors show that for both the getRepairInfo.ps1 and getUserLayers.ps1 scripts:

 

File C:\Citrix User Layer Repair Utility\PowerShell\<script name> cannot be loaded.  The file C:\Citrix User Layer Repair Utility\PowerShell\<script name> is not digitally signed.

+ CategoryInfo : SecurityError: (:) [], ParentContainsErrorRecordException

+ FullyQualifiedErrorID : UnauthorizedAccess

 

As I sanity check, I confirmed I was running the the HTA file as administrator.  I also opened up an admin PowerShell prompt and set the execution policy to remote signed, but still no change.  Since 2.2 didn't encounter this issue and I'm using the same VM, I want to say that this isn't client side.

[Rob Zylowski]

I think you need to set your execution policy to remotesigned so in PowerShell run set-Executionpolicy remotesigned.  Also make sure the scripts are not blocked in windows.

[Rob Zylowski]

Sorry just read you had already set execution policy.  Check the scripts to make sure they aren't blocked.   Just check the windows properties on the file and if it says unblcok chekc the box and apply.

[Jordan Barnartt]

That, did it!  Thanks for the tip about the unblock setting, I wasn't aware of that.

 

It looks like everything in regards to the original issue is working then, thank you for your very quick support that.

 

As an aside, I also notice that if a layer doesn't have a repair file (for example, for our older layers that were captured before the feature was implemented and we've had to need to change since), the item that appears under "Repair File Info" is the repair file name of the layer that is directly above.  Since this doesn't seem like expected behaviour, I thought I'd point it out.  Since it doesn't appear to be impactful, if you can't re-create it or don't have time, it could be left alone.  If this is indeed a bug and you'd like me to test anything, let me know.

[Rob Zylowski]

Thanks ill look at that.  BTW you can regenerate all the repair files by clicking the "Force Repair File Creation" in the setup screen.

[Calvin Chan]

Hi Rob! Firstly, thanks for this tool. Super helpful in doing bulk repairs.. now if I can get User Layer expansion it would be awesome. 

Using version 2.3 and when running "Get Users Layer Size" error result is... 
 

GetULSize.ps1 : Cannot process argument because the value of argument "name" is not valid. Change the value of the "name" argument and run the operation again.