Server error when accessing site via DNS/Load balancer "geolitedbpath ain't presented in web.comfig" - kentico

When on the server where the site is running, it works fine, and no errors show in event log. When hitting via DNS or IP (which is to the load balancer), server error occurs regarding geolitedbpath
I've commented out the reference to this library in the app settings, commented out the calls in the packages.config file, and afaik our application isn't specifically using this. We've run our website for 10+ years and from the point I started, have always seen this error, but never to the point of causing a server error.
This is a new build of K12 portal on new Windows 2016 servers/IIS 10 with plenty of resources etc. The site is a copy of the filesystem of current production which is working.
This is the error in the event logs.
Description:
Message: geolitedbpath ain't presented in web.comfig
Parameter name: geolitedbpath
Exception type: System.ArgumentException
Stack trace:
at CMS.Mvc.Core.GeoProviders.GeoInfoProvider..ctor()
at Global.WriteStateCodeToTheSession(Object sender, EventArgs e)
at CMS.Base.AbstractHandler.CallEventHandler[TArgs](EventHandler1 h, TArgs e) at CMS.Base.AbstractHandler.Raise[TArgs](String partName, List1 list, TArgs e, Boolean important)
at CMS.Base.SimpleHandler2.RaiseExecute(TArgs e) at CMS.Base.SimpleHandler2.StartEvent(TArgs e)
at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Turns out the problem was with the load balancer assigning a profile with no configuration .. setting LB to pass-thru resolved the issue.

Related

Sitefinity upgrade to 10.l2 lost access to blogposts

I am currently trying to upgrade an 8.0 Sitefinity environment to 10.2.6602. This is my first time. The process worked smoothly for the most part but unfortunately as the title suggests I lost access to the blogposts section from the backend and am welcomed with the following when trying to access it:
gERROR - Error: System.Web.HttpException (0x80004005): You are not authorized to access this page
at Telerik.Sitefinity.Web.SitefinityRoute.CheckSecurity(HttpContextBase httpContext, PageSiteNode node)
at Telerik.Sitefinity.Web.SitefinityRoute.GetRouteData(HttpContextBase httpContext)
at System.Web.Routing.RouteCollection.GetRouteData(HttpContextBase httpContext)
at System.Web.Routing.UrlRoutingModule.PostResolveRequestCache(HttpContextBase context)
at System.Web.Routing.UrlRoutingModule.OnApplicationPostResolveRequestCache(Object sender, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
There was no specific issue in the upgrade trace log and I already checked the following:
- the blogs are still present in the database.
- the module seems to be succesfully installed.
- I can access the physical posts from the site.
All I can think off is an issue in one of the config files, if anyone has any advice it would be really helpful as I am at a bit of a loss as to what to try next. Could it be a membership issue?
Thank you for any input you might have.
Regards,
Al.

Kudu on Azure Webapp causes an "Invalid URI: The hostname could not be parsed." exception

Since yesterday (2016-02-11 18:32 EST), we get this mysterious error in our Azure Webapps' "New Relic" monitoring logs. It seems to happens every 5 minutes We have five applications, all were deployed yesterday around that exact time, but the deployment process it the same as before...
The applications are all functional. I do not know where this error comes from, but the Stack trace mentions Kudu.Services.Web.Tracing.TraceModule.OnBeginRequest
Error message
System.UriFormatException: Invalid URI: The hostname could not be parsed.
Stack trace
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Web.Util.UriUtil.BuildUriImpl(String scheme, String serverName, String port, String path, String queryString, Boolean useLegacyRequestUrlGeneration)
at System.Web.Util.UriUtil.BuildUri(String scheme, String serverName, String port, String path, String queryString)
at System.Web.HttpRequest.BuildUrl(Func`1 pathAccessor)
at System.Web.HttpRequest.get_Url()
at Kudu.Services.Web.Tracing.TraceModule.TryConvertSpecialHeadersToEnvironmentVariable(HttpRequestWrapper request)
at Kudu.Services.Web.Tracing.TraceModule.OnBeginRequest(Object sender, EventArgs e)
at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Any ideas what is causing this? Is it a Kudu / Azure issue? Can I do anything about it?
There was indeed a new build of Kudu yesterday that caused this regression (build 51.50211.2078). When it was found, and additional build was deployed (build 51.50212.2079) to address it. However, it doesn't take effect until the site is restarted.
Please try restarting your site and confirm that the issue is gone. If you go to the Kudu home page, you can confirm the version before and after the restart.

Crystal Reports works via HTTP but not via HTTPS

I have searched every where (I think) and I have not been able to find the answer, maybe because it is so elementary but here goes. I recently deployed a Silverlight Business Application to the Windows Azure platform. I am using Crystal Reports for my reporting and everything was working fine. I need to run the app in SSL, so I purchased a certificate and followed the instructions to get the app up and running and again everything works great except for the reports. When I access the site with via http I have no problems printing my reports. But via https I get the following when I attempt print a report:
Unsupported Operation. A document processed by the JRC engine cannot be opened in the C++ stack.
Description:
An unhandled exception occurred during the execution of the current
web request. Please review the stack trace for more information about
the error and where it originated in the code.
Exception Details:
System.Runtime.InteropServices.COMException: Unsupported Operation. A
document processed by the JRC engine cannot be opened in the C++
stack.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
Stack Trace:
[COMException (0x80041811): Unsupported Operation. A document processed by the JRC engine cannot be opened in the C++ stack.]
CrystalDecisions.ReportAppServer.ClientDoc.ReportClientDocumentClass.Open(Object& DocumentPath, Int32 Options) +0
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.Open(Object& DocumentPath, Int32 Options) +147
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +422
[CrystalReportsException: Load report failed.]
CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.EnsureDocumentIsOpened() +549
CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename, OpenReportMethod openMethod, Int16 parentJob) +1613
CrystalDecisions.CrystalReports.Engine.ReportDocument.Load(String filename) +189
COCOBOLO.Web.Files.ReportHandler1.MeetingMinutes() +247
COCOBOLO.Web.Files.ReportHandler1.Page_Load(Object sender, EventArgs e) +2392
System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +25
System.Web.UI.Control.LoadRecursive() +71
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3064
I am almost certain that there is a permission issue using Crystal Reports with SSL but I have no idea what to do. Has anyone had this problem? HELP PLEASE!
since your stack trace shows that Load Report Failed, the first thing i would do is to check whether you have the report in your project and your code is able to access the report.
i know everything works fine using HTTP. Also, make sure that you have read write permissions on the folder where you store your reports.
the problem is not in your crystal report. the problem because ssl don't want to load pdf file.
Display pdf in iframe using ssl/https based
you can try to download pdf viewer in chrome store it's work in ssl and for me.
best regard.

WCAT & TinyGet testing using HttpHandlers

I've searched on Google for an answer to this but there doesn't seem to be much information out there. Does anyone know if you can use WCAT and or TinyGet to test an asp.net application that uses HttpHandlers? I've tried both of these tools and I'm getting an Internal Server Error 500. Looks like a problem with the HttpContext?
[NullReferenceException: Object reference not set to an instance of an object.]
BCT.BaseHttpHandler.Process(HttpContextBase context) +622
BCT.UADTimeHttpHandler.Process(HttpContextBase context) +55
BCT.BaseHttpHandler.ProcessRequest(HttpContext context) +75
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep
.Execute() +181
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& comp
letedSynchronously) +75
I've also tried using the WCAT Fiddler plugin but that has a different error about a possible missing reg key.
Definitely you can. WCAT just makes HTTP requests, exactly like any browser. You've got a bug in your handler, is all. What does the code that the stack trace points to say, here:
BCT.BaseHttpHandler.Process(HttpContextBase context) +622
?

MOSS 2007 site in a farm type initializer exception

We have some solution that we built against a MOSS farm one of which includes a timer job. This job has been working just fine for months. Recently the administrator enlisted another server into the farm, and our timer job automatically started running on this new machine. As soon as this switch happened our timer job started yielding the error below (found this in the SP logs).
At first I thought it was a rights issue, but the timer service on the machine where it worked before and the new one are running under the same domain account. It seems to be failing while looping the site list in a site collection, on just one of the sites/webs (code snippet below). I know that this domain account has access to this because it works on the other box under same account. Does anyone have any ideas on why this cryptic error is occurring? Or if any special procedure needs to be done on this new machine to ensure it has proper ACL's for all databases in the MOSS farm?
Code:
public static void Main(string[] args)
{
SPSecurity.RunWithElevatedPrivileges(delegate() { setInputParameters(); });
}
private static void setInputParameters()
{
SPFarm farm = SPFarm.Local;
SPWebService service = farm.Services.GetValue<SPWebService>("");
foreach (SPWebApplication webApp in service.WebApplications)
{
foreach (SPSite siteCollection in webApp.Sites)
{
using(siteCollection)
{
siteCollection.CatchAccessDeniedException = false;
try
{
/* Here is the line that it fails on */
foreach (SPWeb web in siteCollection.AllWebs)
Exception:
The Execute method of job definition LMSDataImport (ID 4b37b285-ef8a-407c-8652-391639449790) threw an exception.
More information is included below.
The type initializer for 'Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1' threw an exception.
Exception stack trace:
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.get_BackingList()
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.GetEnumerator()
at Microsoft.SharePoint.Administration.SPAlternateUrlCollectionManager.LookupAlternateUrl(Uri canonicalRequestUri)
at Microsoft.SharePoint.Administration.SPAlternateUrl.LookupCore(Uri uri, SPFarm farm)
at Microsoft.SharePoint.Administration.SPWebApplication.Lookup(SPFarm farm, Uri requestUri, Boolean fallbackToHttpContext, SPAlternateUrl& alternateUrl, SiteMapInfo& hostHeaderSiteInfo, Boolean& lookupRequiredContext)
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite)
at Microsoft.SharePoint.Administration.SPSiteCollection.get_Item(String strSiteName)
at Microsoft.SharePoint.Administration.SPSiteCollection.get_Item(Int32 index)
at Microsoft.SharePoint.Administration.SPSiteCollection.ItemAtIndex(Int32 iIndex)
at Microsoft.SharePoint.SPBaseCollection.SPEnumerator.System.Collections.IEnumerator.get_Current()
at LMSDataImporter.setInputParameters()
at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
at Axian.AxianCalendar.LMSDataImporter.Main(String[] args)
at Microsoft.SharePoint.Administration.SPTimerJobInvoke.Invoke(TimerJobExecuteData& data, Int32& result)
Check the DLLs for SharePoint, do all exists and all are the same version? Try putting a catch for the TypeInitializationException, and see what is wrong inside that exception.
It's not a solution, but as a workaround in the interim, I think my suggestion to one of your other questions here:
How do you instruct a SharePoint Farm to run a Timer Job on a specific server?
will keep you running while you investigate further.
Check the NLB (Network Load Balancing) configuration. Most of the time SharePoint and applications integrated to it fails when NLB changes its state. There is a patch available to solve this problem. Just a suggestion. Not sure if this is the reason. But I have faced a similar issue and the root cause was an NLB bug
A Type init exception just means an exception occurred in the .ctor of the class (as you probably know). The real exception should be in the InnerException property - can you get your hands on this? Likely it's stemming from the database alright, from Microsoft.SharePoint.Administration.SPPersistedChildCollection InitializeFromDatabse method.
Can you look into the sharepoint logs (on that errant server) for information about the database error, it will be there. Reading logs are a pain, but not if you install the ULS Log Viewer feature from http://www.codeplex.com/features
Since the stacktrace has SPAlternateUrl tinkering furhter up the stack, perhaps your zones are misconfigured (and do not include a mapping for this new server's machine name) - granted, it shouldn't fail this bad, but what can you do.
You can filter the ULS logs by source.
-Oisin

Resources