i hope that someone got an Idea how i can fix the following problem.
We have XP and Win7 clients in our company.
The clients have Office 2003, Office XP and Office 2010.
A Question first:
Is it possible to add an .ps1 startup script on Windows XP?
Maybe with: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe script.ps1
Executionpolicy on the Clients: Remotesigned (No Cert available!)
If 1 is possible:
Copy the content of \Servername\Netlogon\OutlookSignature\%Username%_CompanySigFolder Path into the following Path C:\Users\%Username%\AppData\Roaming\Microsoft\Signatures\DefaultCompanySignatureName
If 1 is not possible:
I will run a normal .cmd Startup Script 1 day before that copies the Files to %appdata%....
Now the real question:
After the files are copied, is it possible to set the new Signature to the Users Default Outlook Signature?
I have read that it might go via registry entry, but found no detailed information.
I got full access through PS-Remoting to all Computers in the Domain.
Will this work, if an Outlook Session is active?
The Script must distinguish between XP an Win7 an then between Office XP,2003 and 2010.
Thanks in Advance!
Daniel
#Set the signature as default for new emails
$MSWord = New-Object -ComObject word.application
$EmailOptions = $MSWord.EmailOptions
$EmailSignature = $EmailOptions.EmailSignature
$EmailSignature.NewMessageSignature = “name of signature” #insert the signature name
$MSWord.Quit()
Related
Pretty basic script used to create a web shortcut on the PC's desktop, but it's not applying for some reason. I have it set in the gpo under
Computer Configuration->Policies-> Windows Settings-> Scripts-> Startup->
Added the powershell script-> And set it to run the powershell script first.
I also know the script works because I have tried running it manually on the machine without admin privileges or anything and it appears just fine.
$DesktopPath = [Environment]::GetFolderPath("Desktop") + "\Prophet21.url"
$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut($DesktopPath)
$Shortcut.TargetPath = "https://p21.gallagherseals.com/prophet21/#/login" $Shortcut.Save()
You're running the code in the wrong context, to run as a user and affect a user, you need to deploy this as a User Configuration.
When you run a Startup Script for a Computer, this happens when the PC is Domain Joined and will process shortly after displaying the initial login screen silently in the background.
But because there is no user logged in yet, some items aren't available.
To fix this, just deploy it as a User Configuration, the full path to the setting would be:
User Configuration -> Policies -> Windows Settings -> Scripts (Logon / Logoff);
The better approach
However, GPO also natively supports creating Desktop Icons with a nice and easy to use wizard. Just follow this short guide by Praj Dasai. I used to manage GPO and I would always prefer a native solution to running a script.
I want to perform following tasks on Windows 2008 r2 machine -
1) Enable “Do Not Allow Windows Messenger to be run”.
2) Enable “Do Not Automatically Start Windows Messenger Initially”.
To do this, group policy exists on the following path "Open gpedit.msc >Expand Computer configuration > Administrative Templates > Windows components > Windows Messenger"
Need to do this using PowerShell script. How to do it?
In reality, you can easily control this via the regedit in either:
HKCU\Software\Policies\Microsoft\Windows\
or
HKLM\Software\Policies\Microsoft\Windows\
This would work, AFAIK:
Set-GPRegistryValue -Name "WindowsMessenger" -Key "PathToYourTheKeyYoudNeed" -ValueName "xxx" -Type String -Value "YourValue"
This also works with
-type DWORD
Now, I sadly can not really check, where the necessary keys are located, that you would need to control because I do not have any 2008r2 in my company environment.
Hope I could help!
I have created a script that will activate an Outlook Add-in if it is not currently active in the ribbon. This is done by changing the boolean setting on comaddin.connect from false to true. The script only works under certain conditions.
Basically, the issue I've come across is that when you run new-object -comobject Outlook.Application, it will only work if the shell is open in the same mode as Outlook (if Outlook is currently open, which it needs to be). Since the add-in was installed to all users, the boolean setting I need to change is in HKLM which requires the powershell window to be ran in administrator mode. So, I can't work with the Outlook comobject if the shell is in administrator mode, but I can't change the setting I need unless the shell IS in administrator mode.
Note: The below code works if Outlook and the shell are both ran in administrator mode, or if the add-in is uninstalled and reinstalled under the current user only. It doesn't work with the add-in installed to all users, which is what we need unfortunately.
I'm hoping someone out there has a creative way around this! :)
$objoutlook = New-Object -ComObject outlook.application
$objoutlook.application.COMAddIns | where {$_.description -eq "Addin Name Here"} | %{$_.connect=$true}
There is nothing you can do about that, it's a catch-22. the real solution would be for the COM addin itself to hide or show its UI appropriately while staying active at all times.
I am trying to copy one file from share in my custom dsc script. This code below works great in powershell, but not working in dsc resource.
PS C:\Users\user> $wc = New-Object System.Net.WebClient
PS C:\Users\user> $wc.DownloadFile("\\DC1\Downloads\en_sql_server_2012_enterprise_edition_with_service_pack_2_x64_dvd_
4685849.iso", "C:\SQL2012SP2.iso")
Powershell 4/5 has native commandlets for get files from smb share? Or any variants?
As #arco444 alluded to, the way you're doing this is bananas. Why not use Copy-Item?
That aside, I think you would have the problem with Copy-Item as well.
DSC runs under the context of SYSTEM, so you should make sure that your share allows access from the machine account of the machine on which the DSC is to be executed.
Alternatively, you can grant read access to Authenticated Users (which includes all other users as well), or Domain Computers if you're in a domain and want all of the computers to be able to read the contents.
The Credential parameter in file resource is used to connect to the source - so you can specify credentials for the share.
However make sure that credentials are secured as described in this article - [link] http://blogs.msdn.com/b/powershell/archive/2014/01/31/want-to-secure-credentials-in-windows-powershell-desired-state-configuration.aspx
I have installed the PowerShellPack on a Server 2008 R2 machine, but am unable to use the PSImageTools module. All image operations yield the error New-Object : Cannot load COM type Wia.ImageFile. I have tried installing the same package on my Windows 7 laptop, and there it works.
I figure this must be because of missing Dll:s on the server, but even copying the wia*.dll files to System32 from the laptop (there are no corresponding files already in place) helps. It is not possible to register the dlls (regsvr32 wiaaut.dll, for instance), that is replied to with "The file failed to load".
So, has anybody successfully used Wia on Windows Server 2008? We're going to run a scheduled powershell script to update the outlook image of our users, so it needs to be able to run on the server.
I get the same error on Windows Server 2008 x64. Tried both x64 and x86 version of PowerShell v2.
As an alternative you might be able to use System.Drawing.Image. Depends on what your script needs to do. Perhaps post some example code.
http://msdn.microsoft.com/en-us/library/system.drawing.image.aspx
Add-Type -AssemblyName System.Drawing
$image = [System.Drawing.Image]::FromFile("C:\pic.bmp")
EDIT: Here's how you can change an image's dimensions:
$pixWidth = 90
$pixHeight = 90
$image2 = New-Object System.Drawing.Bitmap -ArgumentList $image, $pixWidth, $pixHeight
$image2.Save('C:\new_pic.bmp', [System.Drawing.Imaging.ImageFormat]::Bmp)
Found this article after quite a bit of searching:
http://kb.winzip.com/kb/entry/207/
Basically, you need to enable and set to Automatic the "Windows Image Acquisition" service in Windows 2003, or in Windows 2008, install the Desktop Experience feature first, then enable the "Windows Image Acquisition" service and set to Automatic.