have installed BizTalk 2009 on the following environment:
Windows 2008 server
SQL Server 2008
IIS 7
Visual Studio 2008
I have also installed ESB toolkit 2.0.
The BizTalk applications generally work, except the event log all the time shows this as "information":
"Communication with all MessageBoxes has now been re-established"
No errors appear in the log.
Also when I refresh the ports view in the management console I see they change from "stopped" to "started" and vice versa every few seconds.
Any ideas?
This is normal. The Biztalk process goes into hibernation (a less responsive mode) when there is no work to do. These information messages tell you that a new message has come in and now Biztalk is operating at normal levels.
The error was effectively a bug in Biztalk 2009.
The hotfix was rolled into CU 1, which can be obtained here.
This issue is also resolved in BizTalk 2010.
Related
When I use Visual Studio 2015 to debug a website, using file -> open website... on my local development database, queries slows right down to the point where they take a minute or more instead of milliseconds. Similar queries run by hand using SQL Server Management Studio (SSMS) are slow while Visual Studio is running.
SQL Server instance is running on the same machine as Visual Studio environment.
Here is what I've tried:
Stop Debug mode
After stopping debug, kill IIS Express process
Disabled IntelliTrace
Close solution in Visual Studio
The issue still persists after the above, and the problem is resolved when Visual Studio is shut down or a different solution is opened.
I checked the sql connections from SSMS and the connections were cleared once IIS Express process. It appears to be some sort of integration that Visual Studio is instrumenting with SQL Server libraries that is at the root of this.
Anybody have an idea what this might be or how to troubleshoot this further?
This issue was memory related. If the host that runs SQL server is strained for memory, SQL server will still operate but will bog right down to the point of being essentially inoperable.
My solution was to upgrade my system so that I had a ton of RAM and gave the VM running SQL server and Visual Studio tons of ram. This has the unfortunate side effect of taking for ever to suspend the VM but at least its SQL server is usable with Visual Studio.
I still don't know how to detect by looking at SQL statistics or process monitors. I guess I may need to find/open a new question to drill into this.
I'm configuring a new BizTalk 2016 install, Sql 2016 is installed on a separate server. I get the usual error re missing integration services.
So, at this point I go to Sandro's blog post to remind me what I missed: Sandro's Post
Problem is, the resolution no longer applies because the option for "Management Tools - Basic" / "Management Tools - Complete" is no longer an option, from the Sql Server 2016 Setup Wizard:
So, I go back to the 1st page of the Wizard and Notice the Option for "Install SQL Server Management Tools":
Trouble is, clicking this just attempts to navigate to a page on the web, to download SSMS v17.4. There is no internet connectivity out from this BizTalk server. So, I download from a laptop then get SSMS v17.4 installed onto the BizTalk server. I then restart the BizTalk configuration application (import my previously saved config and re-enter all the passwords!), this does not help with SSIS problem.
Does anyone know what I can install on the BizTalk application server to get around this problem?
Problem was, BizTalk config not happy with the version of SSMS had been installed. Solution was to remove v17.4 then download v16.5.3 from the following and install it: Microsoft Download
I have an ASP.NET web application, and certain operations execute 6 times slower in the full fledged IIS 8.5 on the server versus in Visual Studio's IIS Express.
If I'd try to attach for just debugging I properly see w3wp.exe:
I cannot see w3wp.exe in the Profiler's Attach dialog.
I'm running VS 2017 with Administrator privileges. This is not a remote debugging scenario, both the full-fledged IIS and the debug tools are on the same server (a Windows Server 2012 R2 Essentials if that matters). I'm using Visual Studio 2017 Community Edition.
How can I debug my application in the IIS so I can figure out why it's 6 times slower there? It stuns me because usually it's the other way around: debug and profile versions are much slower than release ones.
Our server BTW is very memory limited. There are two developers working simultaneously and the 16GB physical memory (not upgradeable unfortunately) is topped easily. So I guess the regular IIS is in a memory squeeze by all the developer tools, SQL Server, etc. That might be a reason for slowness, but I don't want a guessing game, I'd like to see a profile session. Profiling VS's IIS Express was super easy BTW. If I see it correctly Visual Studio 2015 didn't even offer the profiling of a Running Process.
Rob was quite terse. First, you need to start Visual Studio in Administrator mode. Besides selecting ASP.NET as Analysis Target in the beginning, once the Profiling Wizard comes up on Page 2 you have to yet again select "An ASP.NET application" instead of your available project, otherwise Visual Studio just fires up a server. After that on Page 3 of 4 I specify the web URL of the application running by my local (non developer) IIS server (http://localhost:8000). Here you have to restart VS in Admin mode if you haven't done so. Then the Performance Output looks like if VS started another server:
Preparing web server for profiling.
Profiling started.
Launching web server with profiling.
Profiling process ID 872 (w3wp).
Starting data collection. The output file is C:\Users\Csaba\Documents\MyProjectSrc\http_localhost_8000__170924.vspx
Profiling process ID 8416 (iexplore).
Attaching to process 8416.
Profiler stopping.
Stopping data collection.
Merging collection data. Please wait...
Data is saved in file C:\Users\Csaba\Documents\MyProjectSrc\http_localhost_8000__170924.vspx
Profiling finished.
After the data collection I saw some spurious errors int he Event log stating that the collection won't be successful. Seemingly it was able to collect data from 3rd party library. But I cannot guarantee it's 100% legit because I didn't examine it thoroughly this time.
Choose "ASP.NET" instead of "Running Process..." when choosing the analysis target.
I was running into some issues trying to run the Profiler (especially since windows home edition doesn't have the full IIS Set by default)
Since you are running Visual Studio 2017, It might be a lot easier to run the new diagnostics tool instead.
The Diagnostics tool is located under
Debug->Windows->Show Diagnostic Tools
It provides the Cpu Analysis and Memory Analysis just like the analyzer does.
You can set a breakpoint and analyze a small section of the code as well.
Back in April, I installed the BizTalk 2009 CU 2 hotfix in our development environment. All local (developer machine) installations were successful and have no problems. However, our QA server installation is having some problems that we cannot seem to rectify.
To provide some background, our QA BizTalk server environment is Windows Server 2003 R2 Standard SP2 running on a six-core AMD Opteron 2435 under VMware. The BizTalk databases are housed on a SQL Server 2008 box external to the BizTalk server. There are several BizTalk hosts configured, each with a single host instance on the QA box.
The problem we're having after the installation of the hotfix is our tracking host instance spikes the server CPU usage to 100% for about 5 minutes, then the host instance shuts down. The host instance will restart itself after a minute, then spike the CPU to 100% again for 5 minutes, repeating the cycle indefinitely. As you can imagine, nothing else can run on the server while the processor is spiking.
We tried deleting and recreating the tracking host instance with a different name but the issue persists. We tried installing the hotfix a second time to no avail. The only solution that works is shutting down the host instance so it can't run.
Has anyone else experienced this issue? What can I do to fix it?
Thanks in advance!
Did you give MsgboxViewer a try? Maybe a huge amount of orphaned instances accumulated.
Most database (Msgbox, DTA, etc.) can be solved using BizTalk Terminator which works hand in hand with MsgboxViewer.
Did you modify any advanced (performance) settings on this host instance?
We have an ASP.NET application written in Visual Studio 2003 (c#) using SQL Server 2000 as database. It’s an old web application that our clients have been using for 4+ years.
Now, we needed to upgrade the application to work on Windows Server 2008 using SQL Server 2008, both 64bit, both on the same machine. So we ported the application to Visual Studio 2008, made some needed modifications and successfully installed the application on Windows Server 2008 with database still being the old SQL Server 2000. Everything worked fine. But as soon as I modified the connection string to work with the new SQL Server 2008 64bit, it stopped working. Basically the web browser just shows – The webpage cannot be displayed; no error messages whatsoever.
I monitored the processess and event log - basically it seems that asp.net worker process is generating errors until it stops working. And I can’t figure out why. All should be fine on SQL Server 2008 side, all protocols enabled, even disabled firewall; i can connect to the instance using Management studio from the same server (64bit) and from other development machines (64bit/32bit).
Then i tried using the web application from my development machine (still Vistual Studio 2003 one, i.e. 32 bit with ASP.NET 1.1) and connect to the new SQL Server 2008 and i got „Server application unavailable“ error. Same thing happens, worker process is generating errors until it stops working.
I used IIS Diagnostic Tool to debug the moment the error occurs – all i got was basically unlimited numbers of „First chance“ exceptions (problems with msvcr80.dll, mscorwks.dll). If I limited the number of those, I also managed to get „Kernel32!TerminateProcess“ exception, which after analysis stated that it didn’t detect any problems with that; only one time i got the warning, describing that 1 client connection was executing for more than 90 seconds.
I dont think the problem is on the 64bit Windows server 2008 or SQL server 2008 side, since when, just for checking, we used Sharepoint application with the new SQL Server 2008 as database, it connected just fine.
So what am I missing with our ASP.NET application configuration/development that it cannot connect to 64 bit Sql server 2008?
Thanks and regards,
Martin.
This sounds like a configuration problem, probably a permissions problem. Your Sql Server is on a different box than the your web server? If so I would look at what user your web site is running under. Make sure that user has access to the Sql Server.
If your user does have access make sure it has access to travel the wire to your SQL Server. Try to connect to the SQL Server via Sql Management Studio with the user's credentials.