Powershell System.__ComObject.document property no longer works under IE 9 - powershell

I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine.
As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it.
Here's the code that will cause an issue:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")
This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error
"Cannot find an overload for "getElementById" and the argument count:
"1"."
I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:
TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}
But under IE 8 I get:
TypeName: mshtml.HTMLDocumentClass
So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.
The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.
Any ideas would be greatly appreciated.

I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.
Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.
Workarounds that worked as temp solution that I didn't like:
Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)
So I set about narrowing down what Office does to enable the COM object required for IE automation by:
Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.
Upgraded to IE11. Ran test script - failed as usual.
Took a VM snapshot
Used Regshot to do record the registry and file system
Ran the Office 2013 Pro_SP1 installation, no changes to default options
When Office install completes, did not run office once (at all ever)
Ran test script again - everything works, the IE automation with getElementById calls all back in operation
Took a 2nd VM snapshot
Ran 2nd scan with regshot and analysed the differences
Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should
I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation
What I did next may not be completely approved but:
I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop
reverted to the pre-office 2013 snapshot
copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l
Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office
So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.
I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.
Hope this helps someone - it was driving me crazy!
Andrew

As detailed in the comments on the question, there seems to be three solutions to this problem.
Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.
The last two solutions come from a different SO answer.

I had similar kind of issue and it got resolved by following below steps:
Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.
Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it.
Below is the link to a method to load assembly at run time.
https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922

Related

MS Visio 2010 hangs when editing UML diagrams

On all four of my Windows 7 x64 Pro computers with Visio Pro 2010 installed, I have had the following problem for the past several months: When I edit a Visio document that uses the UML stencil, as soon as I try to edit any object information, for example, define a table column, Visio locks up. By ‘lock up’, the program ceases to respond, Task Manager shows that the process is consuming 13% of the CPU, and the process has to be terminated via Task Manager.
In an attempt to resolve this problem, I had tried repairing the installation and uninstalling/reinstalling the program, but this has not resolved the problem.
I recently attached Visual Studio to the process to try to better understand the issue. As expected, there were numerous messages of the type ‘Cannot find or open the PDB file.’ The messages which, I sense, may be relevant were as follows:
First-chance exception at 0x7713C54F (KernelBase.dll) in VISIO.EXE: 0x80040155: Interface not registered.
In an attempt to address this issues, I tried:
C:\>regsvr32 c:\Windows\system32\KernelBase.dll
This resulted in a popup window with the following message:
The module “C:\Windows\system32\KernelBase.dll” was loaded but the entry-point DllRegisterServer was not found.
Make sure that “C:\Windows\system32\KernelBase.dll” is a valid DLL or OCX file then try again.
The version of kernelBase.cll that is currently installed is 6.1.7601.24214, dated 1 Aug 2018 with a size of 419,840 bytes.
I used MultiFind Pro to search C:\Windows for any files named KernelBase and found quite a few older version in C:\Windows\winsxs. There were also numerous folder of the type C:\Windows\winsxs\amd64_microsoft-windows-kernelbase_[identifier]. As well as other, similar folders. (What I am finding very strange is that MultiFind Pro is reporting a different file size and date than Windows Explorer or the Windows command prompt DIR command for all versions of this file.)
The last time a Visio UML file was successfully edited was Dec 2017 and based on the modified dates of the files found, the last version of KernelBase that was known to work was version 6.1.7601.23418, dated 18 Jun 2016.
I am fairly certain that my computer does not have a virus. I also know that reinstalling Windows will not resolve the issue as I have the same issue across all of my computers.
If I were to try copying Kernelbase.ddl V6.1.7601.23418 from the winsxs ‘backup’ folder, would it simply get over-written by the newer versions?
More importantly, can anyone suggest a specific course of action to resolve this problem?
Nikolay - I assume you are the MS Engineer who helped me with this issue - thanks.
Without boring everyone with the details: The problem occurs when my password manager, Sticky Password, is also running. Shut it down, and Visio works just fine. I have alerted the company and have asked them to fix the problem.

Windows 10 application issues. Start and Cortana freeze

Recently forced upgraded to windows 10 by microsoft. Windows Start and cortana froze. Searched google and from powershell ran
Get-AppXPackage -AllUsers | Foreach
{Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Now lot of my windows application have disappeared. They show up with #{AppPackageName} in taskmanager or when searched using cortana for example #{Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe}. I can not remove these app using any command like
Tried to install store app manually and get error Merge Failure : error 0x80070003 : Cannot register the Microsoft.WindowsStore_2015.21.25.0_x64__8wekyb3d8bbwe package because there was a merge failure with the following file: C:\Program Files\WindowsApps\Microsoft.WindowsStore_2015.21.25.0_neutral_split.scale-100_8wekyb3d8bbwe\resources.pri
Full log below:
Now I understand that store app is not getting add because add process is causing error or merge failure with another package (?). The problem is get/Add-AppxPackage are resolving dependency of application with package-version: Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.scale-100_8wekyb3d8bbw‌​e
AND/OR
Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.language-hi_8wekyb3d8bbwe
My laptop c:\program files\windowsapp only has Microsoft.WindowsCalculator_10.1510.9020.0_neutral_split.scale-100_8wekyb3d8bbwe (not diff in version 13020 and 9020). Note: The version no on app is 13020 but dependent package on drive is 9020.
Second package is missing from drive (Microsoft.WindowsCalculator_10.1510.13020.0_neutral_split.language-hi_8wekyb3d8‌​bbwe).
How to get my calculator and windows store application back.
<1>Create a new user account and Log into the new account
<2>You can also try
Running the System File Checker by running
sfc /scannow
Download files from Windows Update to replace the corrupt ones by running
DISM /Online /Cleanup-Image /RestoreHealth
You may try the following, at your own risk.
I had the same issue after trying to reinstall the apps via that powershell thingy. Fixed it and returned the apps to their out-of-box state by first wiping everything from C:\Program Files\WindowsApps and C:\Users*\AppData\Local\Packages and then reinstalling Windows over itself from the tech bench ISO (from under Windows and keeping "traditional" apps and files in place, of course). I had to use the ISO because the media creation tool wasn't cooperative at all, throwing some error at me. Just in case, the aforesaid wiping didn't cripple the vitals like the immersive control panel or something else, just the typical no start menu/dead modern apps/no right click on the taskbar items.
By the way, the whole problem started after the 1511 update. Modern apps would refuse to remember their settings, and windows shell experience host would freeze for no reason, taking the start menu and things like volume control with it. I've had this Windows installation for a couple of years now, and the system has gone pretty smoothly through the 8.0-8.1-10 update process over that time, but that 1511 screwed something big time.

PowerShell - SharePoint 2010 - Unable to find type Microsoft.SharePoint

(NOTE: the following problem after appeared after the production server in question underwent system hardening):
I have a PowerShell module that contains the following line:
[OutputType([Microsoft.SharePoint.Publishing.PublishingPage])]
When I open a PowerShell console running as Administrator (as well as being logged in to the server as a sys admin), I get the following:
Unable to find type [Microsoft.SharePoint.Publishing.PublishingPage]: make sure that the assembly containing this type is loaded.
I am able to "force" the Microsoft.SharePoint.Publishing DLL to load with both LoadWithPartialName as well as Add-Type, but then I get the same error with regard to Microsoft.SharePoint when I try to execute my module.
Both DLLs are definitely in the GAC (version 14.0.0.0 as this is SharePoint 2010) and when I view permissions on the GAC, the permissions are sufficient.
As stated previously, the module executed fine previously, and the "Unable to find" error only started occurring after the server in question underwent some system hardening by a third-party. I have tried to investigate the issue from a permissions and group policy standpoint, but so far I do not have any leads.
I am able to somewhat reproduce the error in my dev environment if I completely trash the permissions on my GAC, but this does not truly reflect the situation in production, as the permissions in production appear to be more than sufficient for being able to "see" a DLL in the GAC.
Any help would be greatly appreciated.
You might have better luck with [Microsoft.SharePoint.Publishing.PublishingPage] ;-)
That said, for types that are not part of the BCL, you should use a string instead of a type literal. This allows the module to be loaded - at least - on a machine without sharepoint. That would look like:
[outputtype("Microsoft.SharePoint.Publishing.PublishingPage")]
As far as powershell is concerned, the constraint is the same.
In the end, right-clicking on the PowerShell icon and selecting "Import System Modules" was the solution.
When I changed my OutputType to use quotes instead of brackets, I then received an error that Get-SPSite was not recognized as a cmdlet (selecting "Import System Modules" resolved this error.) I then went back to using brackets for the OutputType and confirmed that "Import System Modules" was all that I needed.

Error R6034 in MSACCESS.EXE followed by Run-time error '-2147023782 (8007045a)'

I have these error messages when I start MS-Access application (has VBA code).
When I click OK in the first error message and debug in the second, the debugger opens up and points to the line that says: "Set oServer = New SQLDMO.SQLServer"
I realise that it's a problem with SQL-DMO, but can't seem to register the DLL.
My environment: Win7 Pro 64-bit, Office 2010 64-bit, MS SQL Server 2008 R2 SP2 64-bit.
I downloaded the backwards compatibility package from Microsoft, ran the MSI, and nothing.
Tried to manually install, and get error messages:
R6034 for C:\Windows\System32\regsvr32.exe and when I click Ok --> The module "SQLDMO.DLL" failed to load. Make sure the binary is stored at the specified path or debug it... blah blah
When I try to register it from C:\Windows\SysWOW64, I get "The module "SQLDMO.DLL" may not (be) compatible with the version of Windows that you're running. Check if the module is compatible with....
I've checked the version of SQLDMO.DLL and it is definitely 64-bit. I have located all the other DLLs that SQL-DMO needs and stored them in SysWOW64 and System32.
I have run Office repair, Windows Update, SQL Server repair (the log file indicates pass for everything for Client Tools Backwards Compatibility).
Any help is much appreciated.
Thanks, Miki.
Not sure how I've managed to, but have (somehow) managed to register the 64-bit SQLDMO.DLL (before it didn't really register it) and then in my VBA code--> Tools --> References... I tried to load the SQLDMO.DLL from the 64-bit folder.
At first, it didn't work, and then I placed a copy of the DLL in SysWOW64 (which is a 32-bit folder) and registered it from there (once it was registered, apparently, the system doesn't need it there anymore - I removed it, and it still works).
I then tried to figure how come it works. I checked in the Reference Table in the VBA Code, and the Microsoft SQLDMO Object Library is still pointing to C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn, but when I removed SQLDMO.DLL from there it still worked... I then looked in C:\Program Files\Microsoft SQL Server\80\Tools\Binn and removed SQLDMO.DLL from there and then it stopped working!
I have no idea what happened, or why the reference table is saying it's pointing to one folder but actually pointing to a different one, or how after the same tries before, only now it works.
I'd like to be able to replicate this (in case I need to go through this process again), so any ideas/suggestions would be greatly appreciated.
Thanks, Miki.

Is it possible to load an instance of a VSTO addin from a network drive?

I've got a VSTO 3.0 Word Addin. Around here, they do all work off network drives (for backup reasons, etc etc).
Anyway, when I'm in the IDE, I can run my project, it automatically starts Word, i can debug, break, etc, just fine.
HOWEVER... If I compile the project, then run Word OUTSIDE of the ide, the Addin registry entry is, of course, still pointing to the NETWORK copy of the VSTO dll, not a local machine (C Drive) copy, and the addin always fails to load.
I can copy the DLL down to the local machine, update the registry to point to the C: location, and then run word and it loads fine.
But I was wondering if there's any way to config VSTO to be able to load an addin from a network share directly.
I've tried setting the "TRUSTED LOCATIONS" in Word 2010 to point to my network location, but it didn't help.
The only oddity in doing so is that the error message I get back from Word when I have VSTO_SUPPRESSDISPLAYALERTS=0, contains a path of file://j:/path/path/path, ie a mapped drive letter.
BUT, when I try to add the j:\path location to my "trusted locations" in word, it always converts it to a full pathspec, ie \domain\dfs\path\path.
I'm wondering if that mismatch is what's screwing it up, but I can't find anyway around it.
Well, as far as I can tell, it's just not possible to load addins on a network drive without running them in the IDE. If someone comes along and knows otherwise, I'd love to know, but I'll go ahead and mark this question closed for now.
Essentially, what I've done is create a little REG script that reregisters the add in to point to the local drive, then, when I need to run as a release (ie NOT in the VS IDE), I compile, copy the dll down locally, and run the regscript. Not great, but not too bad either.
See the registry key to enable VSTO 4 loading of network add-ins here: Installing VSTO 4.0 Causes VSTO 3.0 Addin to quit working