Business Rule Composer (Not Responding) - biztalk

I have BizTalk 2013r2 Dev VM with CU5 installed, apart from the this problem - the VM works great, I have several BizTalk apps deployed locally and all process ok.
When trying to load the Business Rule Composer, it displays but is unresponsive. The title bar reads Microsoft Business Rule Composer (Not Responding). At the foot of the page, in the status bar, there is the message "Loading...".
When I try to apply the CU6 update I get the following (see the Not Responding) in the title bar:
I have checked that all the usual suspect windows services are running, MSDTC, Sql Browser, SQl Server etc.
Any ideas what could be causing this? There are no clues in the Windows Event Log.

I was a able to fix this by running the BizTalk install MSI from the DVD image and selecting "Repair BizTalk"

Related

BizTalk 2016 Missing Sql Management Tools

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

Why would installation method affect .NET service?

I have built a WCF service that is hosted in a Windows Service following this article: http://msdn.microsoft.com/en-us/library/ms733069.aspx. Part of what the code in the service does is join a multicast group and listen for data that is broadcast to the group. Then it processes it. I have found that when I install the service manually using InstallUtil it works fine. To install it manually I do the following:
Build the MyService project in Visual Studio.
Right click on the Visual Studio Command Prompt and choose Run As Administrator
Navigate to the folder that has the MyService.exe file
Run the InstallUtil command as follows: installutil.exe MyService.exe
The service installs in Windows fine and then I start it. Then I run my ASP.NET application which is the client for the service and it runs fine. The service receives and processes the data just fine.
However I am trying to use Advanced Installer to build an MSI or EXE that will install the service and the ASP.NET application all at once so it doesn't have to be done manually. I am able to successfully create the Advanced Installer project that does this and it actually installs both the ASP.NET application and the Windows Service just fine and it starts my Windows Service too. However the really strange thing is that when I run the application I find that my service code can not receive any multicast data. It seems to block on that line of code and I never get any data. Does anyone know why this would happen? I have tried using an EXE and using "Run As Administrator" when I do the Advanced Installer installation. Here is the code from my service.
_groupAddress = IPAddress.Parse(_myIPAddress);
_listener = new UdpClient(_myPort);
_groupEP = new IPEndPoint(_groupAddress, _myPort);
_listener.JoinMulticastGroup(_groupAddress);
byte[] _bytes = _listener.Receive(ref _groupEP);
It seems to block on that last line of code and it never receives any data. This only happens when I install using Advanced Installer. When I install manually it works fine.
A service is configured to run under the identity of a user. Is this different when you install with the different methods?
Do you use the same port number in both cases, if not it could be the firewall.
99% sure that you have checked it, but check that the service is running after it is installed using advanced installer.
Check the event log for problems with the service.
It may be that your Windows Service is not running with sufficient credentials to perform this action. To test this, I'd recommend trying to change the user account being used for the service to see if that makes any difference.
To do this, go to the services applet (start, run, type services.msc). Find your service, right-click, properties, "Log On" tab, choose "This Account" and select an administrator user account that the service can run under.
I initially thought as the guys said this was a problem with the user credentials. But since you said in both cases the service is installed under the LocalSystem the problem seems to be elsewhere.
I recommend you first check the system "Events Viewer" for any messages regarding your message failing to start, maybe there you can find more information about the failure case.
If you can't find more detailed there I suggest a little bit of reverse engineering, to see what InstallUtil does and Advanced Installer doesn't, or the other way around. Advanced Installer comes along with the Repackager tool. You can use this tool to capture the system changes performed when running "InstallUtil" by providing a dummy executable to the Repackager when it is asking for the setup package, for example Notepad.
When the Repackager launches Notepad, leave it open and run your install command for the service, after the service finished installing, close Notepad and leave the repackager do its job. Then analyze the new project that it generates to see what resources has captured, like files, registry, services, etc...
You can also capture the install package create by Advanced Installer to see if the services installation from it creates less or more registration info for your service.

Debugging ASP.NET in IIS 7

I have searched all the usual but come up empty. I must be doing something silly!
Simply I created a new project, ASP.NET Web App, and wish to use and debug it with the local install of IIS 7.5 on my Windows 7 x64 box.
According to what I have read it should be a simple process; my issue is that Visual Studio will not stop at breakpoints nor at errors etc.
I just don't get it:
Visual Studio is attaching to the w3p process for me automatically.
If I hover over the breakpoints it shows a message saying the same, that it is in the same w3p process.
I am in Administrator context. I manually ran it like so to be sure but in any case if you are an admin it runs like that anyway.
Some notes:
I do not wish to use IIS Express as I require native IIS 7.5 for my tasks, however it does debug in express - no surprise there.
As mentioned above, all this is being done locally.
The path of the virtual directory is pointed towards the project files, as set by Visual Studio 2010. It even set the Network Service as read on the folder structure.
When debugging from VS the web site runs fine, just debugging is the issue.
Maybe it is permissions? The Default App Pool is using the ApplicationPoolIdentity not Network Service... Should it be? I had assumed they we.re one and the same essentially. Although I changed this and no luck unless I didn't do something I should of
Keep in mind here that my issue is semi-unique in that I am not receiving error messages, not even in the event logs... For all intents and purposes it should be working fine, just it isn't.
VS and IIS, and all updates, are applied to date.
Note: I'm familiar with IIS7.5, I run my own public web hosting server. I just never tried to debug
Note: It is Visual Studio 2010 Ultimate
Thanks for your time.
Sigh!
I went back to basics... Uninstalled IISExpress and tested; It worked! Re-installed IISExpress; It worked!.
I guess installing IIS7 native after IISExpress did something screwy? I had ran the register ISS command on IIS7 when I installed it.
Right, so now I have both installed in tandem and they work fine. Thanks for all your help guys, appreciated.
you can try right-click on project in VS go to properties select web from left menu tab. Check if ASP.NET debugger is checked and also you can select Use Local IIS Server and give localhost url there (in project Url textbox) and then Say start debugging from VS and put breakpoints.
I had a similar issue the other day, I attached the debugger to the wrong w3p process, make sure you attach it to the one the app pool identity is running under.
I wanted to write it as comment by I don't think I can add pictures..
Are you sure you are running the same version of dll?
Is your breakpoint filled like this?
or hollow like this?
1st go to ,Program and Feature in control panel and then in that turn on or off windows features. and now check all check boxes(activate features) related to Internet Information server & windows service managers. once this is done run your visual studio as administrator and then attach to right w3p process.

asp.net debugging

Have a website going live soon. Have installed VS2008 on my prod server (temporarily) and wish to debug code when I access the actual prod web link. In other words, I want to attached to the w3wp.exe service from w/in VS2008, then open a browser using the prod link of www.xyz.com - thus giving myself the ability to debug an actual prod call - instead of going through the \\localhost:0000.
I am on a Windows 2008R2 server and know VERY little about firewall settings for trying to access this remotely from my home PC...All past attempts have failed.ThanxJerry
If you have the studio installed on the production server just copy all the source code there, point IIS to the folder with your source code and it will be exactly like on your local machine.
If you get errors or other problems, please elaborate - "All past attempts have failed" is not really meaningful.

How do I attach the debugger to IIS instead of ASP.NET Development Server?

I have an ASP.NET website and when I press F5 it automatically attaches to the ASP.NET Development Server, how do I attach to IIS worker process instead when I press F5?
Debug->Attach To Process...
Select the aspnet_wp.exe process from the list.
If you're running IIS > version 5 the process will be w3wp.exe, and there will be one for every app pool (so if you don't know which app pool you're hitting, you'll need to attach to all of them).
open project properties, go to the web tab and choose the option for IIS.
That actually starts an instance of the app in IIS and attaches the debugger. If you only wanted to attach to an existing IIS instance, choose attach to process from the debug menu.
Debug -> Attach to Process from the VS menu.
In order to know to which w3wp.exe process to attach you can use the following command on a 2008 server
c:\%systemroot%\system32\inetsrv\appcmd list wp
While on windows 2003 it is
c:\%systemroot%\system32\cscript iisapp.vbs
For more info see IIS Application pool PID.
However if you have access to the task manager (taskmgr.exe) you can see there directly the name of the process along with the process ID, and in most cases the "user name" column of the process will be the same as the application pool name, (of course you have to set these columns to be visible in task manager in order to view the information).
But note that all of the methods will display only the processes that are currently running, which means that if your particular process has shut down due to idle time you have first to use the site in order to bring the process up in the list.
Also if the application is a "Web Garden" (which has more than one w3wp.exe) then even after attaching to the correct process there is still no guarantee that the breakpoints will be hit, since traffic to the site might be directed to another process.
Also note that if you attach to an application that runs in release mode, it will now instead run in debug mode, which means for example that there will be no timeout limitations (which might be a bit of a problem if you are actually trying to troubleshoot a timeout error).
If you want to attach to a remote process here is the best practice:
Make sure that the firewall is not blocking by opening the relevant ports or completely disabling it (just remember to turn it on again when done).
You should have a windows domain account with administrative privileges on the remote machine or have an account - with the same username and password as the local machine which is running VS - on the remote machine.
On the machine that has VS installed navigate to (Visual Studio Install path)\Microsoft Visual Studio (current version number)\Common7\IDE\Remote Debugger(Remote Machine Version), and copy and paste this folder to the remote machine or share this folder so that it is accessible from the remote machine.
On the remote machine log in as the same user as the local machine (see step 2) from there navigate to the copied or shared folder of step 3, and right click on "msvsmon.exe" and from the context menu select "Run As Administrator".
The Remote Monitor should start up and claim that it started a server usually by the name of (user)#(remote machine) or any other name.
In VS select Debug -> Attach To Process from the menu, leave the transport on "Default" and for the "Qualifier Name" enter the name from step 5.
If everything goes correctly this will bring up the list of processes on the remote machine.
Of course there is a lot more in this subject, and for debugging native code the process might be even simpler, but the steps I have listed here should work in every case.
For farther information you can take a look on http://www.codeproject.com/KB/aspnet/IISRemoteDebugging.aspx or on the MSDN, as well as many posts on this site.
Hope this will help.
Or you can use one of the Attach to IIS plugins to Visual Studio.
My preferred extension is VSCommands (for VS 2010 - 2012 or 2013, but not 2015 yet) or ReAttach (works in 2017).
go to the properties of the web application. Select the "Start Options" section, and change from "USe default web server" to "use custom server". Enter "http://localhost" in the base url.
(assumes VS 2008)

Resources