We're using SSRS to generate database reports that publish to an internally hosted webserver. I'm then writing a PowerShell script that periodically runs and downloads the reports as PDFs.
I've gotten it to work running as an admin. But for security purposes, the automated task must run as a generic domain service account.
The code I use to download the PDF using my account is:
$webClient = New-Object System.Net.WebClient
$webClient.UseDefaultCredentials = $TRUE
$webClient.DownloadFile($ssrsURL, $filePath)
When I run this code as the service account, I get an 500 Internal Server error. I've tried replacing the second line of code with:
$webClient.Credentials = New-Object System.Net.NetworkCredential("Username", "Password", "Domain");
When I try this, I get a 401 Unauthorized error. Even though the Username / Password I put in the code is my own, and works when I log in to the webserver via IE.
The answer may be in my code, domain / local security policies, or SSRS security settings...
Some questions that might be in the right direction are:
What other means of authentication could I try in PowerShell
Does anyone know of any IIS / SSRS settings I could try altering?
What domain or local security policies are allowing "UseDefaultCredentials" to work when run under my account, but not the service account set up?
Thanks in advance for any ideas.
Finally figured it out... it had nothing to do with authenticating with SSRS. My first code snippet works fine.
The issue was in the permissions of the underlying databases. We have five reports, I suddenly noticed that the PowerShell script could download 4 of the 5 reports using the service account. Never noticed because I was always testing on the same report...
Went to the SSRS log file to see why the last one wasn't working - the service account didn't have access to the database that specific report is pulling data from. Hence the 500 error instead of a 401 error.
Related
I have a C# console app that I wrote that is trying to enable mail for an AD user.
using (Runspace EnableMailboxRunspace = RunspaceFactory.CreateRunspace(ConnectionInfo(ExchangeServerURI, ExchangeUser, ExchangePassword)))
{
EnableMailboxRunspace.Open();
// Create a pipeline to process the commands
using (Pipeline EnableMailboxPipeline = EnableMailboxRunspace.CreatePipeline())
This works just fine in the dev environment, but I cannot get it to run on any production server. When the CreatePipeline command is executed I get this error:
"Connecting to remote server pc799.csnt.princegeorge.ca failed with
the following error message : The WinRM client cannot process the
request. It cannot determine the content type of the HTTP response
from the destination computer. The content type is absent or invalid.
For more information, see the about_Remote_Troubleshooting Help
topic."
I have tried this running as multiple different users, including domain admins.
This app did work a few months ago, but now it doesn't work. We moved from a fully on prem system, to a hybrid M365/On prem system and something in that seems to have broke it.
I am trying to send an email via Exchange using PowerShell. Is it possible to specify what version of Exchange to use? I don't know if Send-MailMessage is the correct function to use either.
The server requires username and password, and should use Exchange2007_SP1.
Running the code below returns "Send-MailMessage: Service Not Available. Closing Channel. Server response 4.3.2 Service Not Available".
So it seems that the server gets this, but rejects it.
The secured server that this runs on, has no direct internet connection, but can reach the Exchange server. Hence, I cannot download and install addons to PowerShell, if that is required.
Any ideas out there? Am I attacking this from the wrong angle?
$sendMailParams = #{
From = 'sender#somemailaccount.com'
To = 'johndoe#someexchangeserver.com'
Subject = 'some subject here'
Body = 'some body here'
SMTPServer = 'exchange.server.com'
UseSsl = $true
Credential = $mailCred
}
Send-MailMessage #sendMailParams```
The reason for this not working in the first place is due to PowerShell policies on the terminal servers. For security reasons, sending mail from PowerShell has been disabled, since you can mail to anyone, from anyone. When you log on to the system in the morning, you get a random terminal server. If I'd been logged on to the same one all the time, it might have been an option to enable it on that specific terminal server. But as it is, it is too open to enable it on all servers, so that's why it is restricted.
If things change in the future, it might be an option to do this.
I know this isn't a direct answer to the question, but it is no longer relevant for me. IT says it isn't necessary to specify Exchange version when sending through PowerShell.
Thanks for all your inputs, folks. You are the best.
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
I'm trying to create a pre-build step with powershell in one of our team projects to increment the build number for all assemblies/applications within that VS solution. This is for TFS2015-update 2.
I found some example code here and there online and have pieced together what I imagine would work. I can run the powershell script manually on the TFS server (authenticated to the server as my windows account) and it works fine, but yet it won't function correctly within the build process.
Here is the sample code in question where I keep getting my error. It has to do with authentication/connection to the TFS server:
$CollectionUrl=New-Object System.Uri("$env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI")
$BuildUrl="$env:BUILD_BUILDURI"
# get the team project collection
$TeamProjectCollection=[Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($CollectionUrl)
# get the build server
$BuildServer=$TeamProjectCollection.GetService([Microsoft.TeamFoundation.Build.Client.IBuildServer])
# get the build detail
$BuildDetail=$BuildServer.GetBuild($BuildUrl)
# get the build definition
$BuildDefinition=$BuildDetail.BuildDefinition
There error I am getting is:
Exception calling "GetService" with "1" argument(s): "TF30063: You are not authorized to access http://servername/TPCName
I have tried using both the call above to get the TPC, and the constructer for it and neither works.
$TeamProjectCollection=New-Object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection($CollectionUrl)
So I started trying to build a credential object based on my login credentials to the server and see if I could connect to the TPC that way. Still doesn't work (on server or in build process), but different error:
$netCred = New-Object System.Net.NetworkCredential($username,$password)
$basicCred = New-Object Microsoft.TeamFoundation.Client.BasicAuthCredential($netCred)
$tfsCred = New-Object Microsoft.TeamFoundation.Client.TfsClientCredentials($basicCred)
# get the team project collection
$TeamProjectCollection=New-Object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection($CollectionUrl, $tfsCred)
Throws the exception:
Exception calling "GetService" with "1" argument(s): "TF400324: Team Foundation services are not available from the server.
I have also tried my best at modifying TFS permissions for the windows account that TFS service runs as to make sure there were no issues there. I'm fairly certain I added it to all roles/groups that my identity was in, but still the build wouldn't authenticate.
I'm at a loss at this point. Can someone help me figure out how to connect to the TFS server correctly using defined credentials, or help me adjust what permissions the service account, identity, configuration choices, etc; needed to access the teamProjectCollection.
You need to specifically instruct TFS/VSTS to allow the executing build to call back to TFS/VSTS. This protects your server for malicious developers exiting build scripts.
You should see an "enable Auth" option in the Options Tab of your Build.
**note: You should use the Task SDK provided: https://github.com/Microsoft/vsts-task-lib
Greeting Everyone,
Hoping someone has a quick insight but I am getting access denied on a service account using the PowerShell command Remove-CMDevice.
This process is as per outlined here, https://technet.microsoft.com/en-us/library/jj821759(v=sc.20).aspx
The account has permission to remove devices from SCCM and this works fine through the GUI but not the command line. I have been unable to find documentation on what permissions the account need to do this via command line, it works fine manually in the GUI.
If anyone can shed light on this it will be wonderful, I do want to keep this service account as having as minimal permissions as possible.
Many thanks,
Edit to Add Image as follows,
After a lot of testing, I'm here with an answer on the Permission part when using PowerShell console to remove CM system object. Of course the symptom is the same: The account can delete from Admin console, however, when using PowerShell, it failed with Permission error message.
The account to perform the Remove-CMDevice cmdlet must have proper RBA Permission on the object. Assume the security scope is default one, the account connected to Configuration Manager console must have below RBA permission which I tested is almost minimal permission:
In the screenshot the Collection part, the permission is easy to understand, Read, Delete Resource, etc.
For the Computer Association part, you may get confused, why?
Steps I did the troubleshooting:
I opened a PowerShell Console connecting to Configuration Manager using my test account and run below command to see what will happen:
Remove-CMDevice 'Rsuraceccc' -Verbose
I got below error:
Yes, it's trying to querying from the SMS_StateMigration. Then I try to run a simple command:
Get-WMIObject -NameSpace root\sms\site_clt -Query 'Select * from SMS_StateMigration'
Once again, I got error. So I get the conclusion that the account needs Permission on SMS_StateMigration. So I add 'Recover User State' permission of Computer Association on the role and tried again, cheers, this time all command runs successfully.
I don't know why it's using SMS_StateMigration, but this is the case here.