search

AsBuiltReport / AsBuiltReport.Core

Repository for AsBuiltReport core module
https://www.asbuiltreport.com
MIT License
54 stars 23 forks source link

Exception calling "Save" with "1" argument(s): "Unable to determine the identity of the domain" #17

Closed tpcarman closed 4 years ago

tpcarman commented 5 years ago

Issue by MrZumma Tue Sep 4 16:36:27 2018 Originally opened as https://github.com/tpcarman/As-Built-Report/issues/16

I have narrowed down the module that is throwing the error below in PS. In vSphere\vSphere.json, when the InfoLevel for VMhost is set to 3 or higher, the below error is thrown in the PowerShell window.

I have also disabled all other InfoLevel options except for VMhost, and the error is still thrown. It is not thrown for any other module.

I have tested all four output methods. Only Word and XML output fail with the error below. The HTML and TEXT options create the report as expected and does not throw the error below.

Screenshot image

Desktop

tpcarman commented 5 years ago

Comment by tpcarman Wed Sep 5 00:01:02 2018

Thanks @MrZumma for raising this issue. This is the same issue a work colleague of mine encountered only the other day. Good job on isolating the section, however does the report generate without errors if you disable the VMhost section and leave the others on InfoLevel 3? I suspect it could also be an issue with PScribo which I might ask @iainbrighton to take a look at.

tpcarman commented 5 years ago

Comment by MrZumma Wed Sep 5 14:34:59 2018

You are welcome and glad I can help a little.

While leaving VMhost at InfoLevel 0, I have tested all the others (see exception below) with an InfoLevel of 1 through 5. The error does not occur at any level as long as VMhost is at an InfoLevel of 2 or lower.

** I should have included this initially, but vSAN, NSX, and SRM are not used in our environment. Those three options have remained at an InfoLevel of 0 through all of my testing.

tpcarman commented 5 years ago

Comment by DrBob5188 Sun Sep 9 12:45:16 2018

For what it's worth the issue seems to be caused by the use of isolated storage. There is some information in a comment by Tim Lewis on this blog post. There is a Powershell solution suggested here. I am guessing that running their suggested code before importing the PScribo module may make a difference, but to be honest I couldn't reproduce the fault in the limited testing I have done. Hope that helps.

tpcarman commented 5 years ago

Comment by DrBob5188 Sun Sep 9 13:09:03 2018

I just looked again at New-AsBuiltReport.ps1 and since #requires statements are performed before script execution #requires -Modules @{ModuleName="PScribo";ModuleVersion="0.7.24"} will need to be replaced with import-module PScribo

and the pre-amble code to set the security evidence inserted before the import-module command.

tpcarman commented 5 years ago

Comment by ryan-jan Sun Sep 9 16:45:17 2018

Hi @DrBob5188, thanks for investigating this so thoroughly. I also came to the conclusion that it is caused by PScribo using System.IO.IsolatedStorage. Rather than hack a fix into our script I am hoping that we can get the PScribo source code fixed. I will open an issue on the PScribo repo.

tpcarman commented 5 years ago

Comment by DrBob5188 Sun Sep 9 22:20:44 2018

No problem. I did manage to reproduce the issue and test the preamble code does indeed fix the problem so there is at least that workaround for people having the issue. Also fwiw, my understanding of the problem is that the issue isn't inherently with PScribo but rather the calling app domain. The only fix I could see possible in PScribo would be to track the size of the xml/stream writer and flush it periodically to avoid hitting whatever memory limit makes the .net framework use isolated storage. Seems pretty awful to me though. Hopefully someone with a better understanding of the app domain issue can chip in to explain the issue a little better.

tpcarman commented 5 years ago

Comment by DrBob5188 Sun Sep 9 23:19:49 2018

Ok, I just confirmed it is definitely a problem with the powershell environment. You can reproduce it quite simply with these 2 lines of script `$InitialEvidence = [System.Threading.Thread]::GetDomain().evidence

Note that it fails in plain old PowerShell but works fine in the powershell_ise. I think, although I haven't tested just yet, that the #requires statement will be fine as long as the environment is fixed up prior to making the calls to write the word document.

I couldn't figure out why there would be a different app domain for the caller and the loaded module, but upon reflection there shouldn't be and it's just the initial conditions instantiated by PowerShell.

tpcarman commented 5 years ago

Comment by iainbrighton Tue Sep 11 14:03:25 2018

Sorry - a bit late to the party here as I've just come back off holiday. Is this related to the size of the Word ZIP file created, e.g. when it's over xMB in size?

tpcarman commented 5 years ago

Comment by DrBob5188 Tue Sep 11 20:09:47 2018

Yes it is Ian. I think the magic number is about 8 mb. I can reliably reproduce the issue in PScribo by taking the authoring example and wrapping everything from the first page break through the end of the last section in a for loop. 300 iterations will get me the error, but your mileage may vary. It's a tricky problem since the call to isolatedstorage is buried somewhere in the .NET framework. Apart from the seemingly dodgy workarounds of modifying the appdomain, flushing the xmlwriter periodically or running in the PowerShell ISE I can't see an obvious way around it, but I'll be keen to see where you land on it after examining the issue.

iainbrighton commented 5 years ago

What host OS is this (running the report)? I think I have a solution (it's not elegant) but shouldn't be a problem on later OSes.

tpcarman commented 5 years ago

Hi @iainbrighton,

This is an old, but still relevant issue, which I have moved from the old project repository. We have covered this issue before, as the above, however we are yet to fully resolve it.

The current workaround I suggest is to run the report from PowerShell ISE.

Desktop

OS: Windows 10
Windows PowerShell: 5.1
tpcarman commented 5 years ago

@iainbrighton do you have any further thoughts on a resolution or other possible workarounds to this issue? This will likely become a major issue when PowerShell ISE is no longer available to use, or as we start looking to support PS Core.

nathcoad commented 5 years ago

I can confirm that commenting out #RequiredModules = @(@{ModuleName = 'PScribo'; ModuleVersion = '0.7.24'; }) from AsBuiltReport.Core.psd1 and adding in the powershell solution linked to in Tim's previous post 

$replacementEvidence = New-Object System.Security.Policy.Evidence
$replacementEvidence.AddHost((New-Object System.Security.Policy.Zone ([Security.SecurityZone]::MyComputer)))
$currentAppDomain = [System.Threading.Thread]::GetDomain()
$securityIdentityField = $currentAppDomain.GetType().GetField("_SecurityIdentity", ([System.Reflection.BindingFlags]::Instance -bOr [System.Reflection.BindingFlags]::NonPublic))
$securityIdentityField.SetValue($currentAppDomain,$replacementEvidence)
Import-Module PScribo

worked for me, running the vSphere report over a very large vSphere environment, directly from the powershell command prompt. The resulting docx file was a little over 31MB. Environment - Windows 2008R2, Powershell version 5.1

iainbrighton commented 4 years ago

@tpcarman @nathcoad @mattallford This should hopefully be fixed in the latest PScribo dev branch. If someone could confirm whether this works, it'd be appreciated 😃.

tpcarman commented 4 years ago

Resolved in 4af4399