I want to create a script that will launch an application and configure it completely with provided input values.
ex: Launch outlook-> enter default address-> choose connect ->proceed with next options and finish
How can this be achieved using powershell script?
I am able to launch the applications but not sure how to input values to it.
Ths is a very broad topic, and the answer will depend on the specifics of any given application.
Here is a technet article that dscusses various ways to launch an application, with the benefits and drawbacks of each: https://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx
There are sevaral approaches depending on the app & installer but the basic key is that you must be able to configure the app manually using nothing but command line tools.
If you can do it manually, e.g., one command at a time then scripting the full install becomes easy.
Most/many installers have switches for "silent install" though Outlook is a complicated setup, start there.
Many installers will show there options when you type: InstallerName /?
Usually the options you need are /silent or /q or /quiet and perhaps.
Office has the concept of creating .MST files (t=transform) to provide additional configuration so search for "creating an officer transform" file.
For some apps, you can monitor the registry with a "registry watcher" app and then write a script to make the same/similar settings for each install.
With Outlook, I would first pursue the MST/transform route and ask this question in places where Office and Outlook are discussed.
Related
I want to be able to push a new group policy out with a powershell script (or scripts most likely) that will make all computers on our active domain update to the windows OS that we want. Currently there are hundreds of users and we don't have a way to update their computers other than doing it via remote desktop for each computer individually. But every computer has the .exe file required to update, just hasn't been run yet. Something like
wuauclt.exe /updatenow
I am also open to other suggestion on how to do this. I was thinking of sending all the users a batch file and having them run that and they could do it themselves. Any help would be appreciated and if this post wasn't specific enough I can answer questions or take it down. Thanks!
Never and I mean NEVER let user deploy updates on his/her computer themselves by clicking on some batch or exe file. Two reasons:
It will just not work and big part of machines will not be updated.
You are teaching users that they can run various and unknown batch files / powershell scripts / exe files, because it's safe.
Since you said "hundreds of users" I believe that you have some domain there.
What you might be looking for are the Group Policies (https://learn.microsoft.com/en-us/windows/deployment/update/waas-wufb-group-policy) or WSUS (https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wsus).
Is is possible to lock a powershell file for reading and writing but it can be still run with righ click --> Run with Powershell??
thank you
You can deny the write-access. But to execute a script you have to be able to read it.
Truly securing the credential information is only going to happen through some form of delegation as a layer between the read-able script and the credentials. There are a lot of resources out there for learning about how to securely store passwords for use in scripts.
Try reading about some of the recommendations here:
https://social.technet.microsoft.com/Forums/windows/en-US/8b14f492-88a2-4b25-9ae6-5278a1a8735d/hiding-password-in-the-script?forum=winserverpowershell
If privileged users are the only ones who can read the file, then perhaps you just want an example of obfuscation (relies on trust as it can still be used by those who can read the script):
http://blog.ctglobalservices.com/powershell/rja/store-encrypted-password-in-a-powershell-script/
I currently have a Powershell script that can access Microsoft Outlook, and which I want to be executed automatically every x minutes. For the latter part I created a task in Task Manager that fires the following command:
Powershell.exe -windowstyle minimized -c "powershell -c [PATH_TO_SCRIPT] -verbose >> [PATH_TO_LOG]"
This works perfectly fine, except for the problem that, even with the -windowstyle minimized flag, it still briefly opens a powershell window, that disappears to the background after 2 seconds or so. A solution to this problem is to change the setting in Task Scheduler, checking "Run whether user is logged in or not". However, at that point, my script doesn't execute anymore. From the logs I found that the script runs perfectly fine until the following line:
$outlook = New-Object -ComObject Outlook.Application,
the line on which I open the Outlook application. I'm not sure what the "run whether user is logged in or not" option actually does, but whatever it is, it can no longer access an instance of my Outlook application.
Given what I actually want to achieve, could I tweak either my script or my task to fix this, or is there maybe another way to tackle this?
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. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using a low-level API instead - Extended MAPI. Or just any other third-party wrapper around that API such as Redemption.
I am encountering several situations where, in a Chef recipe with powershell_scipt, a command appears to fail, whereas if I run the same command in powershell outside of Chef, the same command works.
The two in particular are "regedit", which I am trying to use to set a key for app compatibility and the other is "net use z:...." to created a mapped drive. Both of these seem to work fine if I run them in powershell, but if I use them inside a recipe inside powershell_script, they don't appear to do anything.
So I'm wondering is this because Chef runs commands that are inside powershell_script at some lower privilege level?
Also if so, how do I change it so that the regedit and net use would work?
Thanks,
Jim
EDIT 1: This seems to work for adding the registry entry I needed:
registry_key "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags" do
values [{
:name => "{2b9034f3-b661-4d36-a5ef-60ab5a711ace}",
:type => :dword,
:data => 00000004
}]
action :create
end
That prevents the compatability popup that I am getting when we run the Sharepoint installer.
EDIT 2: I hope that this is ok, but for the record and more visibility and hope that I remember this, I found this re. mapping drives in Windows and Chef:
Mount windows shares on a windows node with Chef
and:
https://tickets.opscode.com/browse/CHEF-1267
I haven't tried that yet, but that seems like the answer to my drive mapping need.... hopefully..
The chef client service runs as Local System (SYSTEM) by default.
In Windows, that user has full privileges on the local system, like root basically, but on the network it authenticates as the computer object.
So it you are trying to use regedit to change something in for example HKEY_CURRENT_USER then you need to remember that the code will not see the same "current user" as you will when you run it in interactively. Also, regedit is an .exe; you should really do what you need through the PowerShell providers or .Net objects.
For net use you are trying to map a drive. It's likely that the computer account doesn't have the rights to the share that your user has. Again, net.exe is a separate executable. net use maps a drive to a drive letter (usually) and you shouldn't be doing that in a configuration script, in my opinion. You should access the UNC path directly, but either way I still think that you're probably running into a permissions issue here.
You could change the credentials of the service to use a user account that has all the rights you want, but before doing something like that you should consider changing your workflow to not need that.
I've developed a Powershell script to deploy updates to a suite of applications; including SQL Server database updates.
Next I need a way to execute these scripts on 100+ servers; without manually connecting to each server. "Powershell v2 with remoting" is not an option as it is still in CTP.
Powershell v1 with WinRM looks the most promising, but I can't get feedback from my scripts. The scripts execute, but I need to know about exceptions. The scripts create a log file, is there a way to send the contents of the log file back to the "client" (the local computer making the remote calls)?
Quick answer is No. Long version is, possible but will involve lots of hacks. I developed very similar deployment script/system using PowerShell 2 last year. The remoting feature is the primary reason we put up with the CTP status. PowerShell 1 with WinRM is flaky at best and as you said, no real feedback apart from ok or failed.
Alternative that I considered included using PsExec, which is very much non-standard and may be blocked by firewall. The other approach involves using system management tools such as MS's System Center, but that's just a big hammer for a tiny nail. So you have to pick your poison...
Just a comment on this: The easiest way to capture powershell output is to use the start-transcript cmdlet to pipe console output to a file. We have a small snippet at the start of all our script that sends a log file with the console output from each script to a central file share, and names the log file with script name and date executed so that we'll have an idea of what happened. Its not too hard to pipe all those log files into a database for further processing either. Probably won't seolve all your problems, but would definitely help on the "getting data back" part.
best regards,
Trond