I have an Azure function app that runs some Powershell and as part of it I am importing a custom Powershell module I wrote. I had tested it and it worked, but when I went to test it again it no longer imports the module correctly, it instead gives the following error and I cannot determine why. Because the Powershell on the Azure function is Powershell Core 7.2 and my module requires Windows Powershell 5.1 (its accessing funtions from the AzureAD Powershell module to update a users password and assign a license to that user) I am calling the Import-Module with the -UseWindowsPowershell parameter to enable compatibility.
I've tried several solutions but none of them seem to address the problem, so any help would be greatly appreciated.
ERROR: Failed to generate proxies for remote module 'AzureCon'. The -OutputModule parameter does not resolve to a path, and a user module path cannot be found for the provided name.
I believe this error is not due to PowerShell Code issue.
It is an environment setting variable (PSModulePath) has to be checked.
($env:PSModulePath).split(";")
It was an issue with PSModulePath. Something put in Windows\System32\WindowsPowerShell\Modules into the PSModulePath. I'm guessing when 7 tried to load utility it loaded 5.1 utility instead and blew up. Fun troubleshooting though. Now need to find root cause.
Refer to the Import-Module: Failed to generate proxies for remote module
Update:
Similar ticket raised in MSFT Q&A and it is identified as a new function runtime release broke this functionality.
Thanks to #MayankBargali for the workaround given to fix this issue.
Apology for the inconvenience due to this issue. The workaround is to update the runtime version to 3.8.2.0 by updating the FUNCTION_EXTENSION_VERSION in tha application configuration of your function app if you are running PowerShell function version 7.
The product team will be fixing the issue in the latest runtime.
For the tracking of this issue, refer to the MSFT Q&A 920865.
Related
I'm trying to wrap my hand around DSC in PowerShell 4.0, what's possible, and what's not. I've installed xWebAdministration Module.
Could I create a website in IIS, then somehow export it to the a .ps1 file (I think in the MOF format). For example, txWebAdministration has a sample called xWebAdministration\Examples\Sample_xWebsite_NewWebsite.ps1. Could I use an existing website to build a file like this? Or do I have to type everything in manually?
I'm basically trying to jump in and try some things without reading from end-to-end. I was hoping Get-DscConfiguration would somehow read my IIS configuration and create such a file.
For example, in SQLServer, you can create a database and tables using the graphical user interface of SQL Studio Management Studio (SSMS), then export a script to re-create those same tables on another server.
Is such a concept possible with DSC, or am I missing the boat.
There is nothing like this at the moment.
Keep in mind DSC is very new and quite sparse. The DSC Resource Kit is created by people at Microsoft, but isn't supported or all that official.
You could write a script to parse an existing web site and export it to a configuration in a PS1, or even directly into an MOF (it's a text file too), but there is nothing close to this functionality existing at the moment.
Your best bet is probably to type it out manually at this time.
There is a tool that creates a DSC configuration from an existing machine called GuardRail but I think it will not support the experimental xWebAdministration Module. As briantist said, it wouldn't be too difficult to create a powershell script that uses WebAdministration commandlets to produce a DSC configuration.
In fact a workmate asked me the same question today and I'm considering writing one. If you I'll update my answer in a few days with a script that will do this.
(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.
I've followed the instructions over at http://msdn.microsoft.com/en-us/library/dd193258(v=vs.100).aspx
I've copied the deploy folder and the other dll's over to the remote machine and installed SQL Server 2008 Management Objects. However, when I attempt to run my command (real credentials stripped)
vsdbcmd /a:Import /cs:"Data Source=mydb;Integrated Security=false;Pooling=False;Initial Catalog=dbname;User ID=sa;Password=password;" /model:today.dbschema
I always get the error
The extension type Microsoft.Data.Schema.Sql.Sql100DatabaseSchemaProvider could not be instantiated.
I've searched around, but don't see anything that points to this. Any help please?
I found the issue - the server had .NET 4.0 Client Profile installed. Once I installed the full runtime, this issue went away.
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
While building our project on the Build Server, the compilation fails with the error message:
TlbImp: error TI0000 : The input file 'C:\*.dll' is not a valid type library.
We tried to manually invoke the TlbImp command thru the VS2005 Command Prompt and the same error message appeared.
To investigate, we tried to create a clean build environment in a Virtual Machine (Vbox), then we run the build there. It went fine.
We also tried to invoke the same TlbImp command thru the VS2005 Command Prompt and it succeeded.
With that, we are assuming that there is nothing wrong with the DLL. Do you have any idea what scenario(s) can cause this problem?
EDIT:
Found the problem, see my answer. ;)
If it is working on one machine and not on the other, then most probably some dependency of this DLL is missing in your machine. Inspect the dll through DependencyWalker and you will get to know that which dependency hasn't been built properly.
After closer inspection, we found out that the environment variables on the official build server is FUBAR.
The official build server was installed with both VS2003 and VS2005. Our project is VS2005. The build script is using components from VS2003 instead of VS2005 because the VS2003 paths (Path, LIB, LIBPATH and INCLUDE) were first declared before the VS2005 paths.
A simple SET command to override the environment variables with the "correct ones" fixed the build!
Thanks!