Through a PowerShell script, I'm trying to interact with SCCM 2012 R2 Task Sequences. A lot of sites refer to using something similar to the following:
$tsenv = new-object -ComObject microsoft.sms.tsenvironment
First, if there is a better/different way, I'm totally open to it. But for this way, whenever I run that line, regardless of how I loaded the ConfigurationManager module (e.g. launch PowerShell from SCCM console, load the ConfigurationManager.psd1 from an x86 or x64 PowerShell console), it always returns the error below. I've also tried this on lab SCCM 2012 R2 environments and 2 separate production environments:
"New-Object : Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154 Class not registered"
I'm coming up short searching for answers online, so hoping someone here is able to use that ComObject in PowerShell with SCCM 2012 R2 or if I'm just out of luck.
FYI,
In addition to having an active task sequence, you should also make sure that you are running from x64 process when creating the object when running on 64-bit OS, o/w the creation will fail with the 'Class not registered' error as if there is no TS running.
Related
I am unable to run PowerShell Scripts on Server 2012 R2 Standard.
When I right-click on .ps1 file and run with powershell, nothing happens.. Powershell screen flashes away and exits.
Get-ExecutionPolicy always returns Unrestricted
Can you all guide me if any settings\IT policy requirement that needs to be checked.
An help would be highly appreciated on this.
We have one script server running Windows Server 2012 with PowerShell 4.0 and multiple other servers that run Windows Server 2008R2 with PowerShell 4.0.
What we're trying to do is use the function Get-FSRMQuota from the module FileServerResourceManager found on Server 2012 on the 2008R2 file servers. When in an RDP session on the 2008R2 file server, this can be easily done:
# From PowerShell on the file server:
New-PsSession $ScriptSever
Invoke-Command -Computer $ScriptSever {Import-Module FileServerResourceManager}
Invoke-Command -Computer $ScriptSever {Get-FSRMQuota}
However, all our scripts launch from the script server and are managed there. So we have a job that's initiated on the script server (2012) to run on the 2008R2 servers using PS Remoting. But from within this job it's not possible to import a module from the script server that initiated the job.
So my question, is there a way to import the module FileServerResourceManager from the script server into the remote session on the file server?
I hope I made it clear, as it's a bit difficult to explain. Thank you for your help.
It's not possible. According to https://technet.microsoft.com/en-us/library/jj900651(v=wps.620).aspx, FileServerResourceManager is only available as of Windows 2012.
I have a script used to send mails via Microsoft Outlook from command prompt. This works fine if I run it from inside PowerShell or ISE console. But when I tried to execute same from classic Windows Command prompt (cmd.exe) even with Admin privileges, it was unable to create Outlook COM object. Here is the line to create COM object:
$objOutLook = New-Object -com Outlook.Application
This is how I call my script from cmd.exe (Administrative privileges) :
D:>powershell D:\MiscBuildTasks.ps1 -sendmail -MailTo 'farrukh#MyMail.com'
and here is the error log:
New-Object : Retrieving the COM class factory for component with CLSID
{0006F03A-0000-0000-C000-000000000046} failed due to the following
error: 80080005 Server execution failed (Exception from HRESULT:
0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
At D:\MiscBuildTasks.ps1:81 char:12
+ $Outlook = New-Object -ComObject Outlook.Application
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (:) [New-Object], COMException
+ FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Commands.NewObjectCommand
How can I make it work from cmd.exe (Windows Command Prompt)??
Thanks
CO_E_SERVER_EXEC_FAILURE in case of Outlook means the calling app and the COM server are running in different security contexts. If the command prompt is running with elevated privileges, either make sure Outlook is started with elevated privileges as well or that it does not run at all when your code is executed - this way Outlook will be started by your code and it will run with the same elevated privileges.
I had the same issue, I figured out it was a combination of 3 things.
Running with the correct privilege level (admin)
Using the same arch (32-bit vs 64-bit) for outlook and powershell
Closing Outlook, since the script will open it.
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Office applications assume a user identity when the applications are run, even when Automation starts the applications. The applications try to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM account or the IWAM_[servername] accounts). Therefore, Office may not initialize correctly on startup. In this situation, Office returns an error on the CreateObject function or the CoCreateInstance function. Even if the Office application can be started, other functions may not work correctly if no user profile exists.
If your installation of Outlook is 32-bit, make sure you are using the 32-bit version of PowerShell (x86) and not the 64-bit one.
In my environment I have a single server that has access to pretty much my entire network. That server is running Windows 2008 r2, and I have upgraded Powershell to version 4.0. The question I have is this... Can I run cmdlets from that machine on other machines that are version 4 specific?
For instance, when I am using Powershell, even though it is version 4, it doesn't give me an intellisense autocomplete for "Get-Volume" like it would on a 2012 r2 machine. I understand that it won't run on that machine because the infrastructure won't allow for it, but what about a 2012 r2 machine remotely?
I am looking to run batch scripts from there for various purposes.
First, this is probably a ServerFault-question as it's related to server-administration.
PowerShell 4.0 installed on 2008 R2 can't run 2012 cmdlets on a 2012 R2-machine like Get-Volume -ComputerName My2012Server, because the cmdlets doesn't exist on your 2008 R2 machine. However, you should be able to invoke the cmdlet on the 2012 R2-server, like:
Invoke-Command -ComputerName My2012Server -Scriptblock { Get-Volume }
Be aware that you would not get autocomplete support when writing it as the commands and help files aren't installed on your 2008 R2-server
Import-PSSession is also a possibility if your gonna run the commands interactively. For a script I would probably still use Invoke-Command.
Get-Volume in your example is available only on Windows Server 2012 and above. So, it won't auto-complete on a 2008 R2 system. You can use PowerShell implict remoting.
Using implict remoting, you can import all cmdlets from a remote system into a local session and use them as if they are available on the local system.
Howsit!
I'm in need of a solution, I need to add a snap-in - and can't.
I'm attempting to run processes on my company's share-point site
Thus the real error: Get-SPSite: 'Get SPSite' is not recognized as the name of a cmdlet, function, script file,..
Need to Add a snap-in to solve this (working systematically from example 3: from the site http://technet.microsoft.com/en-us/library/hh849705(v=wps.620).aspx
I am stuck on fourth command (not sure which installutil to select or download?):
It does not exist/ cannot find the installutil: ManagementCmdlets.dll
- does anyone know where to download this?
I tried a file called Microsoft.PowerShell.Commands.Management.dll however
the installation failed, and the rollback has been performed
Powershell code is below (if this may help):
PS C:\Users\Gisintern1.PPF> get-pssnapin -registered
PS C:\Users\Gisintern1.PPF> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil.exe
PS C:\Users\Gisintern1.PPF> installutil C:\Dev\Management\ManagementCmdlets.dll
**Microsoft (R) .NET Framework Installation utility Version 2.0.50727.5420
Copyright (c) Microsoft Corporation. All rights reserved.
Exception occurred while initializing the installation:
System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Dev\Management\ManagementCmdlets.dll' or one of its dependencies.
The system cannot find the file specified..
Per that site, it appears that the ManagementCmdlets.dll is a fictitious snap-in, only used by the example to show how the process works.
I haven't tried managing SharePoint via PowerShell myself, but I did a little digging. From the looks of it, the Get-SPSite snap-in is installed along with SharePoint 2010, and I would assume some other versions of it as well. On the same server that SharePoint is installed on I would try to run:
Add-PsSnapin Microsoft.SharePoint.PowerShell
Get-SPSite
Alternatively (and per https://blogs.technet.com/b/heyscriptingguy/archive/2010/09/20/get-started-managing-sharepoint-2010-with-powershell-cmdlets.aspx) there may be a "SharePoint Management Shell" that can be started which would seem to load the proper snap-in(s) automatically into an otherwise normal PowerShell environment.
Hopefully one of these two ideas helps you out.