SSRS Email not sending but job successfully completed - reporting-services

SSRS Report Service configuration Manager,
I have done Report Service Windows Share its working fine,but the email(gmail) is not sending but the SQL job agent running and completes the job successfully.i am using windows 8 professional system,In many sites SMTP Server manager, is configured but i not have that one i don't know how to handle this issue kindly give me some suggestion to overcome this problem.
Thanks in Advance.

Look into this link, it is a step by step guide of debugging smpt via telnet. It should who why your gmail accounts to not receive a report.

Related

Cannot Access Properties of a Reporting Service Role

Our team has setup a Windows Server to specifically run SSRS in it. We have the reports running well but we wanted to manage several tasks under the Browser role to get rid of a couple of things. I believe this can be accessed through SSMS by logging in to the Report Server. I did this just fine but when I'm trying to open the properties of the Browser role, it is grayed out and can't be selected. Am I doing something wrong here?
A couple of notes to clear things out:
I'm already using an admin account on the server
The Reporting Server is installed separately to a source DB from which we get to access data
I'm able to do this just fine when both Reporting Server and source DB are on the server
I'm using SQL Server 2016 with the same version of SSRS
We have figured it out. We just need to open SSMS as administrator. Might just be a user error of some sort as we do not need to do this on other servers. Thanks.

SSRS 401 unauthorized when connecting to data source

I have searched google and stack overflow before making this post, but i might have missed the answer to my issue.
I have an SSRS report server installed on a server hosting MS SQL server as well. The 2 services is working together just fine and I can do what i expect to do.
The issue is that when my colleagues are trying to connect to the report server URL through Report Builder, they cannot get access. They receive 401 unauthorized error. If they use my login on their machine, they still get no access.
If i use their login on my machine, it works fine.
My conclusion is that its not their logins that is causing this error, and it is not the server configuration either as i can login just fine (i am admin and in the admin AD group, but so is 1 of my colleagues who cant get access).
It must be something on their machine, but i just dont know what or where to look.
Thank you in regards.
You would need to navigate to your SSRS website and assign Report Builder to your colleague's domain\user account.
See here https://learn.microsoft.com/en-us/sql/reporting-services/report-server/configure-report-builder-access?view=sql-server-ver15#:~:text=Click%20the%20gear%20icon%20on,Otherwise%2C%20click%20New%20Role%20Assignment.

SSRS Web page(Hope Page) is Blank

I have installed SSRS 2014 and Configured. When I open the web link from Report Server Configuration Manager I get below message,
I can't see any home page. I am not sure what is missing.
The correct format for the report manager is
http://<Server Name>/Reports/Pages/Folder.aspx?ViewMode=List
Have you solve it yet?
It might happen because the reporting service is not running-make sure the service is running ( can check at sql server config manager) screenshots added.
You can also refresh the service from command prompt by typing:
net stop reporting service
and
net start reporting service
Sql Server Configuration Manager

pass windows credential from IIS to SSRS

I have deployed a couple of reports in SSRS2012, the report uses the user's windows token to do some verification. When testing the report in VS I successfully read the windows token but when I deploy to SSRS token is empty.
I did configure all data sources to use windows authentication and to impersonate the user.
any ideas?
Thanks
I'm a little unclear on the specifics here, but I'm thinking the problem is with the authentication method you're using in IIS.
Check out this other question:
Why does Windows/Integrated Authentication in IIS not pass user credentials to SSRS and SQL?
The versions are a bit different (SSRS 2005) but I think the issues here are the same. I won't get into it too much, because the answer in that link explains it better than I could, but essentially, it works from Visual Studio because your Windows Token is the one making all the requests. When you deploy to IIS, however, without explicitly configuring Windows Authentication and Identity Impersonation, the requests are being executed as the App Pool User, not the user using your web app. I hope this helps!

Dynamics CRM 4 Async Service Jobs Waiting and HTTP Error 401.2

We're having an issue with Dynamics CRM 4.0.
Environment:
Dynamics CRM Enterprise 4.0 Update Rollup 20
Windows 2008 R2, SQL 2008 R2
Platform and Database servers on separate virtual machines
On-Premise deployment
We are using an imported organisation, the web site, outlook connectors and reports are all working without issue.
The issue we're having is that all workflows and system jobs are stuck in the Waiting status. Looking into the organisation database, we see a message like so:
Select Message from AsyncOperationBase where AsyncOperationId = 'SOMETHING';
We see a message that indicates the CrmService returned a 401 Unauthorized.
Using a browser, we can browse to:
http://crmserver/orgname/mscrmservices/2007/CrmService.asmx
and the service is correctly returned, however, when we browse to
http://crmserver/mscrmservices/2007/CrmService.asmx
we receive a 401.2 error.
Additionally, we can access the other services, such as the discovery service, via their normal path (without the org name). It's only the CrmService.asmx that displays the problem.
The CrmAsync and AppPool are all running under Network Service, and this issue is only affecting workflows.
We've tried Unpublishing/Republishing all workflows to no avail. We've run the IFD tool to ensure the server names are correctly set. We have uninstalled/re-installed.
Now we're stuck. Any ideas?
Turns out that the problem was related to hosting WSUS on the same web application as the Dynamics CRM service.
Fixed the problem by reinstalling Dynamics CRM to its own web application.