I am trying to convert Word file(s) to PDF. I have found a code that is using ComObject Word.Application.
However, running the command:
$word = New-Object -ComObject word.application returns the following error:
`New-Object : Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception
from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
At line:1 char:9
$word = New-Object -ComObject word.application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo : ResourceUnavailable: (:) [New-Object], COMException
FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Commands.NewObjectCommand`
I have MS Word installed and running fine.
I have found that my PowerShell is running 64-bit version but my Office installed as 32-bit. This may be an issue but I cannot control it as the script will be powered by 3rd party application that I have no control over and Office is installed on many computers that I really do not control also.
Can I somehow register that Class? Can I do the conversion without any 3rd party software (like Word or LibreOffice) installed? Any other suggestions?
Thanks
Need to create a PDF file
I was not running as Admin.
However, I noticed that the same script was running fine on my other computer and everything seems the same on both of them. So, I have done the "repair" of the Office installation and that has fixed the issue.
Related
I'm sorry that this is quite alien to me, but I had a previously working script that functioned like the following:
$wd = new-object -comobject word.application
but when I print the COM object it has empty/blank values for all attributes.
PS C:\Users\XXX> $wd
Application :
Creator :
Parent :
Name :
Documents :
Windows :
ActiveDocument :
ActiveWindow :
Selection :
And it cannot set any or perform any functions
PS C:\Users\XXX> $wd.Visible = $true
Exception setting "Visible": "Unable to cast COM object of type 'Microsoft.Office.Interop.Word.ApplicationClass' to interface type 'Microsoft.Office.Interop.Word._Application'. This
operation failed because the QueryInterface call on the COM component for the interface with IID '{00020970-0000-0000-C000-000000000046}' failed due to the following error: Error loading
type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))."
At line:1 char:1
+ $wd.Visible = $true
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], SetValueInvocationException
+ FullyQualifiedErrorId : ExceptionWhenSetting
I tried browsing related questions but was unable to see if the mistakes are exactly identical. I've run all Windows updates and did a repair installation of Office. (Running Windows 10 and Office 2013)
Sometimes Word/Excel/PPT COM Objects are acting wildly. Thus using these is not recommended for automation purposes by Microsoft itself (sorry but couldn't find the source). But whatever personally I use those all the time :).
System Restore or closing and repoening the Powershell Session actually fixes those problems for me.
Unfortunately I couldn't figured out a programmatic way to handle this yet. So looking forward for further answers. (+1)
I'm trying to write some scripts for Azure Active Directory / Office online, and I'm completely unable to install the MSOnline powershell module. I've installed the Office Sign In Assistant version 7.2 (64-bit for my 64-bit machine). When I try to run the MSI installer for the PowerShell module, it says it can't find the sign in assistant. When I install the powershell module through PowerShellGet, and then run the commands, it fails with:
Connect-MsolService : The Microsoft Online Services Module is not configured properly. Please uninstall and then reinstall the module.
At line:1 char:1
+ Connect-MsolService
+ ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], InvalidConfigurationException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.InvalidConfigurationException,Microsoft.Online.Administration.Automation.ConnectMsolService
Connect-MsolService : Object reference not set to an instance of an object.
At line:1 char:1
+ Connect-MsolService
+ ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Connect-MsolService], NullReferenceException
+ FullyQualifiedErrorId : System.NullReferenceException,Microsoft.Online.Administration.Automation.ConnectMsolService
Is there any way to get this installed ? I've even changed the language of my system to US-English and installed the correct language pack (because I've run into issues before with things not installing correctly if the system language is not US English)
Found at least a partial answer here that worked (at least got the module working again for one of my accounts, the other one still fails and remains a mystery):
MSOnline can't be imported on PowerShell (Connect-MsolService error)
In my case, some registry keys were missing (I don't know why) and reinstalling didn't help. I imported the registry keys with one path adaption from another system and now it works. I used the following registry keys (just copy to a file powershell.reg, change InstallPath if necessary, and import):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOnlinePowerShell]
"Version"="1.0.0"
"InstallPath"="c:\\Program Files\\WindowsPowerShell\\Modules\\MSOnline\\1.0\\"
"InstallLanguage"="en-us"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOnlinePowerShell\Path]
"WebServiceUrl"="https://provisioningapi.microsoftonline.com/provisioningwebservice.svc"
"FederationProviderIdentifier"="microsoftonline.com"
Follow the steps to install the Azure AD Module here
I am currently using the following sequence of commands in a Windows 7 PowerShell window.
Add-Type -Path "C:\Program Files (x86)\AWS SDK for .NET\bin\Net35\AWSSDK.dll"
$secretKeyID="ABCDEFGHIJKLMNOPQRS"
$secretAccessKeyID="LONGKEYBLAHBLAHBLAHBLAHBLABLAH"
$AWSclient=[Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID,$secretAccessKeyID)
However, I get this exception below. Please let me know what Im doing wrong. This is what I see most people using successfully.
Exception calling "CreateAmazonS3Client" with "2" argument(s): "No RegionEndpoint or ServiceURL configured"
At line:1 char:1
+ $oAWSclient=[Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID,$secret ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : AmazonClientException
One thing that I think is a problem is that my bucket is not checked for 'enable website hosting'. Does this need to be set to true? I just want to upload a file to the bucked via powershell script.
Duh... I realized that I need to use the AWS Powershell because it has all the settings built into it. Im not exactly sure how to properly refer to this version of powershell, but it is available after installing the AWS SDK.
Since the error specifically states that you're missing the RegionEndpoint or ServiceURL, you could also just include one of them. Since you're connecting to S3, all you need is to include the RegionEndpoint.
Add-Type -Path "C:\Program Files (x86)\AWS SDK for .NET\bin\Net35\AWSSDK.dll"
$secretKeyID="ABCDEFGHIJKLMNOPQRS"
$secretAccessKeyID="LONGKEYBLAHBLAHBLAHBLAHBLABLAH"
$client = [Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID, $secretAccessKeyID, [Amazon.RegionEndpoint]::USEast1)
(Replace USEast1 with the value configured with your S3 Bucket)
I got the Request to unzip a .zip file with Powershell. On the Internet i found the following code multiple times:
param( [String]$newlocation, [String]$filepath)
if(($newlocation -and $filepath) -and ((test-path $newlocation) -and (test-path $filepath)))
{
Copy-Item $filepath $newlocation
$shell_app=new-object -com shell.application
$filename = $filepath.split("\")[-1]
if(Test-Path "$newlocation\$filename")
{
$zip_file = $shell_app.namespace("$newlocation\$filename")
$destination = $shell_app.namespace($newlocation)
$destination.Copyhere($zip_file.items())
}
}
As I implemented it into my script it changed a little bit. This above is the changed version. Now I've got an error:
Exception calling "NameSpace" with "1" argument(s): "The system cannot find the file specified. (Exception from HRESULT
: 0x80070002)"
At Z:\MyScripts\deploy.ps1:34 char:34
+ $zip_file = $shell_app.namespace <<<< ("$newlocation\$filename")
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ComMethodTargetInvocation
And then another one, that is quite clear (caused by the first error
You cannot call a method on a null-valued expression.
At Z:\MyScripts\deploy.ps1:36 char:39
+ $destination.Copyhere($zip_file.items <<<< ())
+ CategoryInfo : InvalidOperation: (items:String) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
The File and the destination Path both exist and I've got rights to acces them (I created both). I'm running on Windows XP with PowerShell 2.0
Major Minor Build Revision
----- ----- ----- --------
2 0 -1 -1
Here is my entire dump from Powershell when I run it directly on the console.
I hope you guys can help me or at least tell me where I can go to find an answer.
I tried already to unzip the zip file manually and it worked, I have got access to both, the file and the file path (as I created both).
I've found this one on the web:
Also the code looks to me like it's dependent on the Windows Explorer support for zipFolders, which you may have turned off
Unregister (disable) XP Zip folders
REGSVR32 /u C:\Windows\System32\zipfldr.dll
Register (enable) XP Zip folders
REGSVR32 zipfldr.dll
It's from here.
I came to it during testing my script on several machines, e.g. on a Windows Server 2008 and on a Windows 7 client. Both worked, so I came to the conclusion that it's not my script,but it's my PC. After the registration of XP Zip folders, it worked.
Many thanks to the guy who wrote this one, I dumped too much time into this problem.
You might be running into a problem with accessing the COM objects. If you are using 64-bit windows, make sure you execute your script from a 64-bit powershell.exe. This means the powershell.exe in c:\windows\system32...\v1.0.... This was counter-intuitive for me, having the '32' in system32. I was executing powershell from Console2, which was a 32bit process, and was therefore launching 32-bit powershell (from c:\windows\syswow64...). Also make sure your powershell.exe is being run with administrator privileges.
Instead of trying to automate the Windows Shell, now in .NET Framework 4.5 there is a ZipFile class that you can use like this:
[System.Reflection.Assembly]::LoadWithPartialName('System.IO.Compression.FileSystem')
[System.IO.Compression.ZipFile]::ExtractToDirectory($sourceFile, $targetFolder)
Edit: Oops, .NET Framework 4.5 is not supported on Windows XP.
Anyhow, this answer might still prove useful for anyone else with ZIP problems in Powershell…
I'm trying to deploy my first web part on 2010. I developed a web part using VS2008 and tested it on SP2007.
I copied the CAB to the 2010 server and tried to use the power shell to install it:
PS C:\Users\sa_portalt> Install-SPWebPartPack -LiteralPath "c:\transfer\webparts\redirectwebpart.cab" -Name "RedirectWebPart"
Install-SPWebPartPack : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:22
+ Install-SPWebPartPack <<<< -LiteralPath "c:\transfer\webparts\redirectwebpart.cab" -Name "RedirectWebPart"
+ CategoryInfo : InvalidArgument: (:) [Install-SPWebPartPack], ParameterBindingException
+ FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.SharePoint.PowerShell.SPCmdletInstallWebPartPack
What am I doing wrong? Is this the right way to install web parts?
If you can, I recommend you upgrade to Visual Studio 2010 which has built-in support for SharePoint 2010. When you build a project built from the SharePoint template it will create the wsp for you. You can also immediately deploy to the local server from VS2010 so you never need to get into PowerShell on your local development machine.
When you need to deploy to a different server, you can then run
Add-SPSolution -LiteralPath C:\webparts\MyWebPart.wsp to add the solution to Central Administation
and then
Install-SPSolution -Identify MyWebPart.wsp -WebApplication http://mySharePointserver to deploy the solution to the specified web application
This was the first article I found that provided the actual answer, however, in the Install-SPSolution, there is a typeo, the -Indentify parameter should be -Identity
Also, in most cases (if adding to the GAC) need to add the -GACDeployment to the Install-SPSolution.
So the line should look like:
Install-SPSolution -Identity BasicWebPart.wsp -WebApplication http://vsp -GACDeployment