What good tools can I use to monitor IIS. What is included seems to be not as useful as I'd like. I realize I can add performance counters; those don't tell me very much; it's just a collections of properties that are plugged into a generic graphing tool.
I have problems with old legacy applications hanging and various and sundry other things. Also, when I need to get basic information like how many connections I have in IIS and their details I don't know what to do. I've googled extensively and I cannot find much. I find some log parsers, but I want real time. I found some commerical tools that don't really seem quite what I want, besides I'd like to find something free. This is very basic stuff that is pretty easy to get in Apache. I found IISTracer but I am a bit skeptical of it; I did install and try it out. Is there anything else? Some of these legacy applications are classic ASP so just a CLR Profiler isn't what I'm looking for, although those are handy.
EDIT: Is IISTracer really the only tool like this out there for IIS?
Tools for Troubleshooting IIS 6.0
IIS Request Monitor (IIS 6.0)
One of the techniques for tracking down and mitigating problems with badly behaving sites is to use Application Pools. This article shows how to set one up.
It has also been mentioned here on SO:
What causes an application pool in IIS to recycle?
Pros and cons of having dedicated application pools over keeping web applications in one default app pool
Related
I will start working on a Project soon, and as I am a noob in regards to coding (and general indecisiveness due to the lack of knowledge), I would like to have some suggestions in regards to what type of Windows (forms) application I should build (eg. payroll system, library system, etc)
I know there are a lot of ideas out there, but I would like some suggestions of an easy system to build, including a system that is easy to expand on. Will also make use of a database (connecting SQL Server to the application)
I will be using .NET / C# (VS)
Thank you in advance.
In my experience 90% of the commercial systems I've been hired to write just involve relatively basic storage and manipulation of data with some layers of security around access.
Maybe start with something like a payroll system, but keep in the back of your mind that you could scale to accommodate a full HRMIS (Human Resources Management Information System). Also, experiment with ASP.NET MVC and Web Technologies, in my experience, the majority of systems now are moving to a web-based implementation.
The possibilities are endless in the world of software development.
You could make a winforms program that calculates all the primenumbers between two user inputs. You could also then output these to a XML-file, and make a button that lets the user open an XML-file and reload whatever they input back then.
It's pretty simple, but still involves some Winforms basics and some XML data storage/manipulation.
We recently had a 3rd party auditor perform a penetration test on our MS 2008 webserver that uncovered remote OS detection vulnerability. It detected the OS as well as version of IIS.
The Auditors recommended: "if Possible, configure the web server so that it does not present identifiable information in the banners"
I've done quite a bit of research and I could not find any easy way that will allow me to quickly block this information from being detected.
Does anyone know of any way to do this? Is this something that needs to be configured/denied on the server level or web application level within the code?
URLScan is what you'd use back in the IIS 6 days, not sure if it still works with IIS 7 or 7.5. This is a bit of security by obscurity, and quite honestly most attacks spray everything they have at you and don't care if you are presenting yourself as IIS, they'll throw apache attacks at you or vise-versa.
On top of that there are plenty of things, besides banners that give the server away. The order at which they present their info in the header is different between IIS, Apache, Weblogic, etc. httprint is one such utility: http://net-square.com/httprint/
On top of that you have programs like Satori and p0f that do passive OS identification based on the TCP stack and/or other means.
So yeah, go back to the auditor and ask them what specifically they are recommending, and why! Taking out the extremely low hanging fruit of the banner is one thing, but honestly, unless you have a script kiddie, with a script that ONLY looks at banner information, you aren't protecting yourself from much of anything.
I am developing socket reading on an ActiveX EXE (i.e on a seperate thread).
How many sockets i can safely read independently?
I am working on windows XP OS.
I think this might be an operating system limit - I think I remember running up against a limit of 80 sockets on the XP machine I was using several years ago.
I would recommend that you abandon your effort and go with a commercial solution. I remember going down this path back in the 90s and running into a brick wall with ActiveX EXEs as far as threading goes. The thing is that ActiveX EXEs are apartment threaded, not free-threaded, so you don't get completely independent threads.
And doing server side threads properly is hard enough in modern languages, let alone ones that weren't designed for this purpose.
I ended up purchasing Server Sockets from Dart. Easily the best investment for that project. The performance is truly great - you are only limited by the system resources.
MSWINSCK.OCX is a very old way of doing things; it came with Visual Basic 6.0 and i remember using it way back when. i'm not sure the licensing on it... apparently it registers fine under 32-bit win7, but not 64-bit; here's a link to how to get it to register on 64-bit systems: http://angrybyte.com/windows-hacks/mswinsck-ocx-for-64-bit-windows-7-vista/
if you have an MSDN subscription or similar that gives you the ability to download the developer tools (bizSpark, etc. will do it too) then i believe that will also give you a license to redistribute the .ocx.
(btw, i don't actually remember the interface, but i seem to remember it being at least slightly more intuitive than the berkeley socket() interfaces.)
however, personal recommendation given your requirements: learn the APIs, there are lots of examples out there, and just write yourself a class that encapsulates them in a similar way as, say, the .NET Socket class... the APIs aren't that hard and i'm sure there's lots of help to be had here as well, and that's probably better than relying on something that's out-of-date like the control...
It takes at least 7 assemblies and restricting my AddIn's data model to data types that remoting can deal with before the appdomain isolation features begin to work. It is so complex! The System.AddIn teams blog implies to me they were trying to re-create a mental model of COM, a model I never understood very well in the first place and am not sold on the benefits. (If COM is so good why's it dead?-rhetorical question.) If I don't need to mirror or interop with legacy COM (like VSTO does using System.AddIn), is it possible to just create some classes that load load in a new AppDomain?
I can write the discovery code my self, I've done it before and a naive implementation is pretty fast because I'm not like iterating over the assemblies in the GAC!
So my specific question is, can I get the AppDomain isolation that AddIns provide with a few code Remoting snippets, and what would those be?
I'm not entirely sure that that any answer to your question meets the terms of the site - there is no solution.
Yes, remoting is easier as it is done for you. However, it is highly controlled and as you identified, requires a little work to plumb it all together. The cache file spewed out by the discovery process is hardly welcome either.
System.AddIn excels at isolation, which is actually a bit of an arse to put together from scratch in a robust, flexible way. It supports cross process hosting and fairly simple passage of user WPF elements from one domain to another.
One thing to remember however is that MAF's target audience is not those who are trying to connect two applications together. It is targeting developers wanting pluggable yet secure systems (cross process hosting protects the root application from unhandled exceptions, appdomains allow for executing potentially foreign code with defined security). From most communication, direct yourself straight towards System.Runtime.Remoting or WCF.
If you want to continue with System.AddIn, consider the pipeline builder plugin for visual studio!
In conclusion - you can get System.AddIn isolation using Remoting but to get a decent system you will require more than a few snippets. I am trying to replicate it myself and am tripping up all over remote interface component - something System.AddIn does without a hitch.
After messing around with System.Add for quite a while, I'm convinced that it was added as a one-off special purpose solution for Microsoft use. I'm surprised it got elevated to a core part of the .NET framework. It doesn't seem to have the refinement and polish needed for a general .NET framework component.
I'd like to find an alternative way to create .NET managed add-ins that doesn't require so much effort.
I'm having trouble deciding if I want a project of mine to be web-based (as in a web-app), desktop-based (a desktop application), or a desktop application that can sync or connect to the cloud.
I don't know if anyone else would have an interest in this application, and it's only going to be for me, so I'm leaning toward desktop application. If, for some reason, I finish it, release it, and people actually like it, I might see about making it sync to the cloud as well (think v2). But I'm not sure how hard it is to make such a radical change, and I don't want to end up with something good that is useless because I made a poor choice before I even started the project.
Is there any sort of guidance for this? Any rules of thumb or best practices? Any personal experiences?
If the language matters, I'm thinking about Java simply because I'm most comfortable with it, and it would easily allow me to share it with my friends for testing and if I get stuck and need help from someone else in person.
I generally ask a few questions:
Can it even be done on the web? Something I did not too long ago involved an image editing component, and had to be a web app. It involved much pain to get this work, and a desktop app would have been a far better way to go.
Will I need to access it from anywhere? Yeah you could load it up on a thumb drive, but the web is far more feasible in this case.
Will there be multiple users? This could go either way, but "long tail" stuff usually means web.
What tech do you want to use? The latest and greatest WPF based UI? Desktop (yeah yeah, silverlight, let's not go there ok?). The brain dead stupid easy user management of Django or others? Web.
If it were a web app, will you need to worry about common attack vectors like SQL Injection, XSS, etc? A desktop app has its own issues here too, but tend to have less exposure.
How resource intensive is it? Will 10 users kill performance of a web server?
Versioning on the desktop can be a pain, whereas with a webapp everyone is on the same version. This can bite you though, see the New Facebook user pushback.
EDIT:
Cost can be a factor too. A web app with a database backend typically means a web server. If you want to stick with, say, the Microsoft Stack, you'll need licenses for SQL Server which can get pricey. Open source is cheaper, but may not be an option in all cases. "Serving" a desktop app is generally cheaper.
If you release as a web-app, you won't have to port it over. You'll also have access to it wherever you go.
I base my choice on the GUI mostly. If the GUI is going to be complex, and (needs to be fast or will have aspects of it that will take a lot of time to process) then I will go with the Desktop. If it is simple, and will always have small data sets to work with at once, the I will go with the Web.
I have worked on an app that was made as a web app, when clearly it was better suited for the desktop. It was a massive failure. I don't know HOW customers put up with it, cause I certainly wouldn't have used it. The desktop version (which took over 6 months to re-write) blew the web version out of the water.
That being said, I have seen some nice web apps.
All I can suggest are several factors that would be relevant. How you determine the answer and weight for the factor is up to you and other circumstances:
What is your audience? Do you have any control over them?
How complex are the interactions you expect to implement?
Do you require near real-time data updates?
How often do you expect to update the application after the first release?
Do you expect a well-defined set of client platforms, or can you not predict that?
Note that your choices also can include a Java WebStart application, which mitigates some of the disadvantages of a typical desktop application.
I'd say that most applications should be desktop-based. The advantages are faster and more fluid apps.
You should only create a web application if there are obvious benefits from it, like access from everywhere. (If that's necessary for your app.)
A downside of web applications can also be that it is dependent on the developer, if you quit supporting it all your users (if you'll have any) can't use it anymore. Furthermore, there is a chance that users are not willing to store their data online.
Ultimately it depends on what kind of an application you want to write. Even if you create it as a desktop-app, you can later on rewrite it for the web. Often a 2.0 version of software needs almost complete rewriting anyway.
Sometime web can be good and sometime not. We are in a new wave that go in the web but do not forget few things:
GUI in web is more complicated because of multiple browser
People who need to work on your system might not like working the whole day in a browser
Web can be slower for some application (image editing, hard job that require a lot of CPU)
Rapid Gui like Visual Studio for winform are faster than for web
But web has many advantage in the deployement and in the portability. If your system is well structured you could make both or change to one to other later with something build with MVC. Just change your visual and you will be fine.
If this were an application to be used my multiple users, with shared data, you're probably going to want a server anyway. In that case I'd lean towards a web application.
Otherwise you've got the complexity of syncing data between the desktop and a server.
Two important questions not on the list so far:
Will the first version have any features that need lowish-level access to hardware?
Will future versions have any featuers that need lowish-level access to hardware?
It's pretty easy to answer the first one, but giving the second one some thought can save you some headache down the road.
My default choice is to go with a web solution, as it's easier to deploy and generally multi-platform. The only time I go with winforms apps is when there are pressing security, performance, or functionality issues that require it.
Previously you'd have written a desktop application, as tool were better for that and you'd have written it faster. People used to want web apps, but always ended up with desktop.
Nowadays things are different, you can write a webservice just as quickly and easily so there's no reason not to go web-based.
The advantages of web-based are flexibility, scalability and ease of deployment. It won't be as responsive as a desktop app could be, but that's not so much of an issue if you think about your design.