I've followed the dnn 7 installation videos to make a single server install. The only slight deviation I made was to create a database up front as demonstrated in the video. I'm using SQL Server Express rather than the full-fat SQL Server, but I followed the install for full fat SQL Server. I did this because I don't understand the conventional way of using SQL Sever Express, when I try to attach to the MDF file from SSMS it tells me that it's locked - even after stopping IIS!
Anyhow, for my first installation using the dnndev.me domain everything worked great.
I then tried to repeat the installation but this time using a real domain - you can see it at www.rotherweb.co.uk. The problem is that the site always gets redirected to the page gettingstarted.aspx.
I have pasted output from Fiddler below:
Result Protocol Host URL Body Caching Content-Type Process Comments Custom
1 200 HTTP www.rotherweb.co.uk /Home.aspx 6,839 private text/html; charset=utf-8 chrome:4200
2 200 HTTP www.rotherweb.co.uk /Resources/Shared/scripts/DotNetNukeAjaxShared.js?=1357564157543 3,393 application/x-javascript chrome:4200
3 200 HTTP www.rotherweb.co.uk /GettingStarted.aspx 7,793 private text/html; charset=utf-8 chrome:4200
4 200 HTTP www.rotherweb.co.uk /Resources/Shared/scripts/widgets.js?=1357564157763 3,732 application/x-javascript chrome:4200
I have noticed that the working website for dnndev.me has sub folders of \portals\0\images , \cache, \Templates, \Users . However the failed website contains only \portals\0\cache. So this would suggest something failed during the installation but when I click to see the installation logs I get "No Installation Log"
Could anyone please help?
Thanks in advance
Rob.
I managed to work around this by creating a database in the default folder c:\program files(x86)\Microsofoft SQL Server etc...
I'm not sure why having the db a different folder caused a problem because I had granted file permission to the folder for the account of the host app pool. If I get chance I will go back and dig a little more.
Related
How to host ASPNET CORE APP with IdentityServer4 in IIS. The app is running fine from localhost but not as a web application setup in IIS.
For Example,
http://localhost:5000/connect/token is working but http://example.com/myauthapp/connect/token is not reachable - returning 500 - internal server error when tried from a console app using identity model or via postman. I am able to login to the app using web browser but not thru a console app or postman.
Further Troubleshoot and I find the below.
An unhandled exception has occurred: IDX10638: Cannot created the SignatureProvider, 'key.HasPrivateKey' is false, cannot create signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
System.InvalidOperationException: IDX10638: Cannot created the SignatureProvider, 'key.HasPrivateKey' is false, cannot create signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
at Microsoft.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(SecurityKey key, String algorithm, Boolean willCreateSignatures)
at Microsoft.IdentityModel.Tokens.CryptoProviderFactory.CreateSignatureProvider(SecurityKey key, String algorithm, Boolean willCreateSignatures)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.CreateEncodedSignature(String input, SigningCredentials signingCredentials)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.WriteToken(SecurityToken token)
at IdentityServer4.Services.DefaultTokenCreationService.CreateJwtAsync(JwtSecurityToken jwt)
at IdentityServer4.Services.DefaultTokenCreationService.<CreateTokenAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
How can I solve this issue?
As Arun noted in his comment, the certificate has to be installed on the server.
1 . To test this on localhost first, make sure you are using "AddSigningCredential" not "AddTemporarySigningCredential".
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2(Path.Combine(_environment.ContentRootPath, "certs", "IdentityServer4Auth.pfx")));
//.AddTemporarySigningCredential()
;
Create the certificate in your project (create certs folder), running this in visual studio command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert" -n
"CN=IdentityServer4Auth" -a sha256 -sv IdentityServer4Auth.pvk -r
IdentityServer4Auth.cer -b 01/01/2017 -e 01/01/2025
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx" -pvk IdentityServer4Auth.pvk
-spc IdentityServer4Auth.cer -pfx IdentityServer4Auth.pfx
Test on localhost
If successful, deploy to iis server , install the certificate on the server by double clicking on it, and test.
Make sure the application pool "load user profile" is set to true :
Go to IIS Manager
Go to the application pool instance
Click advanced settings
Under Process model, set Load User Profile to true
Restart IIS
If this fails with a 500, like with me (and there is no logs to help you out), try this. To fix this recreate the certificate on the server the same way as in step 2 in the certs folder . double click the cert to install.
You might have to install the developer kit if you dont have visual studio installed:
https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk
A little background first, on why it is working on your Local Development computer and not running under IIS on a QA or Production Environment. If you are using Temporary Signing Credential when adding the service Identity Server 4 like so,
services.AddIdentityServer().AddTemporarySigningCredential();
Then you have to make sure the "User" that the "Process" is running as has a Private Key available for ID4 to create a Temporary Certificate. This is why the error message is
SignatureProvider, 'key.HasPrivateKey' is false, cannot create
signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
In the case of Windows, this private key is generated by Windows automatically and can be found at the folder %APPDATA%\Microsoft\Crypto\RSA of the User or C:\Users\Username\AppData\Roaming\Microsoft\Crypto\RSA. The reason why this Private Key is missing is perhaps because the User that your Process is running as has never logged onto that Computer.
The likely SOLUTION in that case is to log in once as the User that will be running the Process on that Server. It is quite common for the Private Key directory to be missing if your Application Pool within IIS runs as a "non-service" user with very High Privileges and that user has never interactively logged onto the Server itself. This also explains why "localhost" works on your development computer, while running on a Production or QA Server may not.
More information on how and where Windows creates the Private Key for a User can be found here in this link Microsoft Key Storage and Retrieval. Also, it is recommended as mentioned by David Smit to explicitly specify a Private Key file, instead of using Temporary Signing Credentials. That is the cleaner solution if you are allowed to make code changes.
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2("C:\Certs\IdentityServer4PrivateKeyFile.pfx")));
How do I resolve this issue with requests to msmdpump.dll for connections to SQL Server Analysis Services? I am receiving a 500 Error from the IsapiModule.
On a Windows Server 2012 R2 machine, with IIS 8.5, I have setup the OLAP data pump (msmdpump.dll), using the following instructions: https://msdn.microsoft.com/en-us/library/gg492140.aspx#bkmk_copy
The application pool is configured for .NET CLR v4.0, with Classic Managed pipeline mode. The identity is set to a local service account. (I have also tried a domain account, and I have tried making the local user an Administrator).
I've created an application under the Default Web Site, called OLAP, with an IsapiModule, as per the MSDN article.
As far as I can tell (and I've double and triple checked), everything is configured as laid out in the MSDN article. Also, compared to another server where I have this setup (on a different network), it is essentially the same.
When I request http://localhost/OLAP/msmdpump.dll in a browser on that machine, I receive a 500 Internal Server Error. The error indicates that it is trying to use the OLAP handler that I created. This is not the same error that I would normally expect when doing a GET request to msmdpump.dll. The normal error for a straight GET, when everything is working correctly, is sent back in a SOAP envelope. In my case, the request does not appear to ever be processed by msmdpump.dll.
500 Internal Server Error via browser:
(see below for full screenshot)
Module IsapiModule
Notification ExecuteRequestHandler
Handler OLAP
Error Code 0x8007007e
Requested URL http://localhost:80/OLAP/msmdpump.dll
Physical Path C:\inetpub\wwwroot\OLAP\msmdpump.dll
Logon Method Anonymous
Logon User Anonymous
500 Internal Server Error via SSMS connection:
I also receive an error when trying to connect to the data pump via SQL Server Management Studio:
Screenshot of the 500 error in the browser:
One appreciable difference between the machine I'm setting up, and the server where the data pump already works, is that there are a few more roles setup on the new server.
The problem server includes:
.NET Extensibility 4.5
ASP.NET 4.5
While the other machine (where the data pump works), does not include those roles. Would the presence of ASP.NET 4.5 or .NET Extensibility 4.5 cause an issue with IIS serving requests for this IsapiModule?
Quick answer
In my case installing KB3138367 (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) resolved the issue.
Longer answer
There are a few debugging steps that can be useful.
Configure IIS tracing
For full instructions see: https://learn.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
However, you can ignore the parts where it tells you to delete your existing content - they're going a little overboard there to ensure you get the same results in the tutorial. Just add the failed request tracing to your existing site, catching "500" status codes.
In my case, that led me to the result:
ModuleName IsapiModule
Notification EXECUTE_REQUEST_HANDLER
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode The specified module could not be found. (0x8007007e)
I confirmed that my handler mappings had the correct path to msmdpump.dll, but still got the error. So time for the next debugging step:
Use Sysinternal Process Monitor to check w3wp.exe
Process monitor is a free tool from Microsoft: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Use Process Monitor to log file system access (filter on the "w3wp.exe" process to avoid being overwhelmed)
Look for NAME NOT FOUND and PROCESS NOT FOUND results. There will be a number of these as the system attempts to e.g. locate various dlls, so it is normal to see some NOT FOUND results followed by SUCCESS results for the same filename. You are looking for NOT FOUND results that do not have any corresponding SUCCESS results.
In my case, this highlighted two dlls:
msvcr120.dll
msvcp120.dll
These turn out to be part of the “Microsoft Visual C++ 2013 Redistributable” package (https://superuser.com/questions/1163409/msvcp120-dll-and-msvcr120-dll-are-missing).
However, "Add/Remove Programs" showed that the package was already installed. Running "repair" on the package did not resolve the issue.
Locating the dlls
In my case, the OLAP pump is installed an a web server separate from Analysis Services.
Running these powershell commands:
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcr120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcp120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
yielded some interesting results. On the web server, the dlls only showed in C:\Windows\SysWOW64.
However, on the server where Analysis Services was installed, the dlls were present in both C:\Windows\System32 and C:\Windows\SysWOW64 (as well as a few other sql server paths)
(as an aside, SysWOW64 contains 32 bit dlls, and System32 may contain 64 bit dlls. So simply copying from SysWOW64 to System32 is likely to cause you problems. See https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows)
I could see from the Process Monitor logs on the web server that one of the search paths was C:\Windows\System32. A little more searching led to KB3138367 (Installing both Visual Studio 2013 Redistributable packages (x86 & x64) at the same time)
The actual KB text (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) describes the issue:
When you install an updated redistributable package, binaries for
non-target architectures are removed. For example, after you install
an update for an x86-based application, the x64 Visual C++ 2013
runtime libraries are missing. This fix makes sure that both versions
of the Visual C++ redistributable are visible when you add or remove
programs after installation of the update.
You should probably disable Anonymous Authentication on IIS
This is the perfect article, as expected to see on stackoverflow! I even thought that this case is also mine, but thorough checks shown my problem was crushing msmdpump.dll, and that crash was an exception, caught internally by msmdpump.dll. The only visible clue was a message in Windows Application log stating "an internal error happened" (or smth. alike). Googling alot didn't bring any valuable results, but suddenly this article gave me an idea to check for the LATEST MSQL cumulative update from here, and, after installing it and re-coping msmdpump.dll the crash was gone and cubes finally shown up as expected in SSMS interface. Needless to say that all issues with IIS Identity Pool, double-hop and other security-related stuff was rechecked many times with no success... Realizing that exception is inside the dll itself take some time to come...
Preface: Installed SQL Server 2016 RC0 and installed and configured Reporting Services all fine, thoughts maybe on potential conflicts with existing SSRS instances?
Issue with SQL Server 2012 Reporting Services, every time I navigate through the configuration manager to either the Web Service URL or the Report Manager URL, I get the following errors:
Report Manager URL returns
HTTP 500 error
Console when opening the Report Manager URL returns
SCRIPT16389: Unspecified error.
http_500.htm (1,1)
HTML1524: Invalid HTML5 DOCTYPE. Consider using the interoperable form
!DOCTYPE html
.http_500.htm (1,1)
Web Service URL returns
The version of the report server database is either in a format that
is not valid, or it cannot be read. The found version is 'C.0.9.45'.
The expected version is '162'. (rsInvalidReportServerDatabase) Get
Online Help
Console when opening the Web Service URL returns,
GET http://localhost:8085/ReportServer_MYREPORTS 500 (Server Error)
To try and resolve this, i've already tried adding RSExecRole to RoleMembers under both ReportServer$MyReports and ReportServer$MyReportsTempDB.
Also tried recreating ReportServer database under the Config Manager, but get the following error.
Generating Database Script - Error:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: An error occurred when attempting to connect to the report server remote procedure call (RPC) end point.
I can confirm that both RPC services, SSRS Services are running with no problems, and also restarted these services multiple times.
I have realised that my ReportServer$MyReports is missing the DBUpgradeHistory table.
Any thoughts?
This will fix the issue right away:
delete from dbo.ServerUpgradeHistory where ServerVersion=[The wrong or upgraded version]
In my case, there was no "ServerUpgradeHistory" table. I needed to install SSRS 2012 on a machine that already had SSRS 2016 to do regression testing for a client that doesn't want to upgrade their system.
What I discovered is that there are SharePoint settings that SSRS installs even if you don't install SharePoint or SharePoint Plugins on your box.
Here's what fixed the problem for me:
Navigate your File Explorer to C:\Windows\assembly\GAC_MSIL\
Note there are many directories in here that have nothing to do with SSRS. We will just focus on seven directories that appear to be related to this problem.
Navigate to Policy.11.0.Microsoft.ReportingServices.Alerting
Enter the assembly directory. This is usually a series of digits followed by a hexadecimal identifier.
E.G. 13.0.0.0__89845dcd8080cc91
This path will vary based on what is installed on the machine
Backup the config file in case you need to roll back changes
E.G. from a Command prompt: COPY *.config *.bak
Open the config file.
Look for the text in the newVersion attribute of the bindingRedirect tag:
<bindingRedirect oldVersion="11.0.0.0" newVersion="13.0.0.0">
Modify this to use "11.0.0.0"
<bindingRedirect oldVersion="11.0.0.0" newVersion="11.0.0.0">
Save your changes
Repeat steps 2 through 8 with the following subpaths:
Policy.11.0.Microsoft.ReportingServices.SharePoint.Common
Policy.11.0.Microsoft.ReportingServices.SharePoint.ObjectModel
Policy.11.0.Microsoft.ReportingServices.SharePoint.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint.SharedService
Policy.11.0.Microsoft.ReportingServices.SharePoint12.Server
Policy.11.0.Microsoft.ReportingServices.SharePoint14.Server
Reboot your computer
We have been using JBoss Wildfly 8.2 for about 9 months and never had this issue until about two weeks ago (Nov 9th 2015 approximately). We use IIS 7.5 on Windows 2008R2. We serve .war files with Java/JavaScript and also server ColdFusion separately. We connect to MSSQL Server 2012. All of this has been the same with out the errors. We also use Spring and SOLR. We use SiteMinder.
What happens:
User goes to our website, they see a blank screen with the IE11 tab stating 500 error. After some minutes, the user can refresh and the site will be up fine. We have confirmed that two users at once will experience the same thing. As far as suspected browser configuration issues, the user does not need to do anything. They just wait 5-15 mins and then click refresh. Now that I think of it ... maybe the 500 error resolves after I have logged in remotely, but I am not 100% sure.
This does not happen every day, and we have 4 different sites with the exact same software and VM setup (IIS / .war file / etc is the same) and it happens to different sites randomly.
It is ALWAYS the first users in the morning that I have seen so far.
There are no server logs after 02:00 AM ... the site is trying to be accessed at around 6:00 AM. JBoss shows no indication of any errors and everything looks just fine in the back end. Our last error is: 23 Nov 15 02:00:03,915 ERROR [stderr] (Timer-6) java.net.ConnectException: Connection refused: connect -- this is expected since that is DB maintenance time. After that ... nothing.
The Application Logs in Server Manager show the following at the time of the 500 error:
New virus definition file loaded
Then 6+ occurrences:
Failed to initialize the message bus
SiteMinder agent has encountered initialization errors and will not service requests
Server already running Duplicate LLAWP processes not allowed, exiting
Then I log into the server successfully and shortly after I see
The Software Protection service is starting
Then, random or not, the site seems to be up and logs say Software Protection service has started.
What the heck is going on and how do I fix this? It seems coincidental that the 500 server error goes away after I log in, but still...
So I posted a new blog on my site and promoted it on my facebook where the traffic spike was far bigger than anticipated, the server went down from the volume of traffic and after it was rebooted I am now getting a database connection error.
I contacted my server host and they told me this:
"I was able to get the relevant database details from the wp-config.php file in the home directory for your site and, using those creds I am able to connect to the relevant database without a problem.
To be sure that I was able to connect AND make a query to the database I have also created a simple test script that can be viewed at http://yoursite.com/mysqltest.php
This confirms that the server is responding correctly and that the database itself is able to accept connections and queries.
This leaves us with the likelihood that the issue lies with the scripting/configuration of the wordpress installation which is not something I am going to be able to assist you with.
I suspect that the problem lies with the wp-config.php file but cannot be certain."
I can't see how the wp-config would have changed, I haven't touched it in over a month and it's been working fine otherwise. The website was also working fine after I posted that blog, it was only after the server was rebooted that it doesn't. All the other sites on the server remain in perfect working condition. I don't see how a traffic spike could have done this. I'm lost as to what to do next? Please help! :(
D
Try this database connection test script https://gist.github.com/162913