WMI access to IIS7 - iis-7

We have an internal tool that enumerates the IIS sites and applications for a server. It uses code similar to this:
using (var serverManager = ServerManager.OpenRemote(serverName))
{
var site = serverManager.Sites[siteName]; // This is slow
// And just starting to enumerate Applications is incredibly slow
foreach (var application in site.Applications)
{
// ...
}
}
The problem I'm having is that when the Sites collection is accessed, the response time is really slow when connecting to a server over our VPN. Accessing the applications for a site is even slower. My theory is that the slowness is caused by the fact that the entire set of metadata for the sites is probably sent over the wire. However, I only need a subset of the site data.
My theory is that if I switched the code to using WMI queries, I'd be able to query for only the specific fields that concern this application (like SELECT Name from Site). Unfortunately, when trying to explore WMI objects in WMI CIM Studio, even for my local IIS 7.5, none of the objects I'd expect to be present, like Site and Application objects. I'm using root\WebAdministration for the namespace.
Does any of this WMI stuff work for IIS 7.5? I ensured that the "IIS 6 WMI Compatibility" is turned on. Are there any alternative lightweight ways to query the metadata for an IIS instance?

You can manage IIS 7.5 via WMI and the simplest WQL query SELECT Name from Site will output the list of available sites. See "Managing Sites with IIS 7.0's WMI Provider".
Note: if you intend to use scripts for IIS6, you may be required to rewrite them. Most scripts for IIS6 won't work with IIS7 because methods in WMI provider of IIS 6 and IIS7 are different.
You can start CIM Studio this way:
Share C:\Program Files (x86)\WMI Tools on your network and set Read / Write access for your account to the share.
Start IE and enter \\hostname\WMI Tools\studio.htm URL.
If you still can't start WMI Studio, use wbemtest tool to explore root\WebAdministration namespace.

Related

Best method to connect IIS 7.5 Web Forms to SQL Server

I'm upgrading an ASP.NET 4.0 app from:
Windows Server 2003 and IIS 6
to:
Windows Server 2008 and IIS 7.5
This app is based on ASP.NET Web Forms and not MVC. I currently use SQL authentication, but I would like to follow best practices in the new environment.
Both the IIS 7.5 machine and the SQL Server 2008 machine will reside in a DMZ with its own domain controller. It would be nice if we could use similar connection strings for Dev, Test and Prod environments. What's the best practice for this situation? I've read about three options.
ApplicationPoolIdentity
Create your own service account on the domain
SQL authentication
Here are links to questions that discussed related issues, but nothing seemed to answer my specific question.
User ASP.NET Runs Under
Assign Permissions to ApplicationPoolIdentity Account
I recommend AD account for running the app pool. Then, permissions can be created at SQL server for that same account. The conn string used by the app will then not have to contain account info at all (trusted connection), and you will have one less thing to worry about related to security. As additional precaution, remove that AD account from all user groups, and don't use it for anything else but for this one thing (the app pool). Give that user read access to website files, and write access only to folders that it needs to write to (e.g. to dump log files).
As far as best practices is concerned, I don't think any of the 3 options you listed is better over the other one; all of them can do the job securely and efficiently if used correctly. Your decision should be based on which of those offers advantages to you considering your particular environment, company policies, etc., but again, none of them are bad practice.

What is the simplest way to deploy an ASP.NET MVC 3 site to multiple clients that are not already running a web server?

Our server application runs as a service and has a ASP.NET MVC3 web-based frontend that connects to our application for monitoring and configuration. Our application is generally installed on client servers that are maintained by their IT departments so I'm trying to figure out the best way to package and deploy the ASP.NET portion of our application to make it as painless as possible to run on their servers.
It seems like the official way to run an ASP.NET MVC3 site is to deploy it to an IIS server installation. Since we would like to avoid pushing the additional overhead of providing, installing, and maintaining a full web server onto our clients it seems that it would be best if we could give them a package that was entirely self-contained and just ran a second service alongside our application. The web frontend is for internal use only so scaling isn't much of a concern.
Any ideas?
The simplest way is to host it yourselves. I frequently make technology decisions for my team, and having the option to pay you to host an instance for me is 100% my preference.
Ultimately, the alternative is the client having a web server. You cannot just set it up for them, because IIS requires administration and configuration to be secure and work in the client's environment.
Since there weren't a lot of responses here I'm answering with what I ended up doing in case anyone runs across this in the future.
We ended up using IIS Express. We're going to distribute the IIS Express installer along with our installer (allowed by the IIS Express license: http://blogs.iis.net/vaidyg/archive/2011/01/17/iis-7-5-express-official-release-highlights.aspx). Once installed we use CreateProcess to directly run iisexpress.exe with the /path set to our ASP.NET project so the entire thing is completely controlled by our existing service (and we can route output into our logging system). We use Job Objects to ensure that the IIS Express process is killed if our service crashes.
We do something like this to shutdown IIS Express:
for( HWND currentWindow = GetTopWindow(NULL); currentWindow != NULL; currentWindow = GetWindow( currentWindow, GW_HWNDNEXT ) )
{
DWORD currentWindowProcessId;
GetWindowThreadProcessId( currentWindow, &currentWindowProcessId );
if( currentWindowProcessId == m_processId )
{
PostMessage( currentWindow, WM_QUIT, NULL, NULL );
break;
}
}
We haven't put this into production yet, but it's been working great so far during development.

ASP.Net web site on IIS connecting to Access DB with Links to SharePoint lists on another machine

My Problem is the following,
I have an ASP.Net web site hosted on IIS. This web site connects to an Access 2007 DB file on the same server. The DB file contains links to sharepoint lists on another server on the same domain. If I run the web site on the visual studio built-in server, I can Open connection to the DB file and retrieve data just fine. But whenever I try to run the web site over the IIS, the web site can't open a connection with the DB file.
What do you think the problem is?
Thanks.
It will be a permissions problem. When you run with Visual Studio's web server it is running as you, IIS on the other hand runs (by default) as Network Service. This is limited in what it can do.
To access an access database (no pun intended) the account that IIS runs under will need the ability to read, write, execute, change and delete for the directory the database is in. By default this should be granted to the APP_DATA directory, if your access database is elsewhere you will need to grant these permissions.
Connecting via Access to a remote machine is a whole other problem, it's unlikely this will work because the Network Service account is a local account and will not exist on the sharepoint server, and you cannot grant access because it does not exist.
If you were in a domain you could run IIS under a suitable locked down domain account and it might work, but frankly it's all a bit messy!
Have a look at this article:
How to connect to a remote Access database from Active Server Pages
http://support.microsoft.com/kb/253580
Yes, I know your database is on the same machine, but there are differences in permissions and authentication for files and folders when you run IIS. The chances are good that whatever is hanging you up is covered in this article.
Whether mixing Access databases and IIS is a Good Thing or not is a separate discussion...
Access 2007 makes connecting to SharePoint a breeze. After you link to a list, then ADO, and even DAO + VBA code and your sql queries work on those lists!
I seen a good number of people thus start using the JET (actually it called ACE in access 2007) as a data connector to SharePoint for this very reason. Since your are building a web based system then we not using ms-access here, but ONLY using the 2007 version of the JET data engine that ships with access 2007.
Someone does need to come out with a OLEDB provider for SharePoint lists that allows ones web site or .net code to view those lists as standard sql tables like ms-access can. Using JET as the data connector system is likely not such a good idea. I do realize that you not storing nor placing data in the access JET table, but are using the wonderful ability of the new access JET engine to view and use SharePoint lists as regular sql tables. This approach does allow your ASP.net code to execute sql updates on that data or do whatever as if this was a regular sql table. It does make this oh so easy.
The security permissions on the SharePoint site are thus going to view this connection as not as a end user, but always see the USER as the actual web site connecting (or at least the user you were in ms-access when you linked the table to SharePoint). I don’t believe the SharePoint user authentication process can work reliable when you do this. What will happen is you change a few things on the SharePoint site, and next thing you know the JET connection will be trying to prompt you for new logon credentials. You can’t provide nor control those logon credentials at that point in time.
So, as others pointed out, this is going to be problematic and not reliable.
Using Access as a fudge to access SharePoint from an ASP.net site is going to give you lots of pain in the long run.
A much better way would be to use SharePoint's web services to access that data - removing Access from the equation altogether.
http://www.scribd.com/doc/8634090/Accessing-SharePoint-Data-Using-C-Without-Running-Code-On-the-SharePoint-Server-Part-1
MSDN - Using ASP.NET web services
Creating and Consuming a Web Service

SQL Express User Instance with multiple ASP.NET Sites

How can I get two separate ASP.NET sites, in this case a Web Site using Entity Framework and Web Service, to use the same local database mdf & ldf?
I looked around and I think that this kind of local DB is called a User Instance - at least they way I'm currently using it. I wasn't sure if it would work or not until I found the below info from the MSDN Library and now I'm really not sure if it will work.
User instance scenarios include:
...
Dedicated ASP.NET hosting using Windows Authentication. A single SQL Server Express instance can be hosted on an intranet. The application connects using the ASPNET Windows account, not by using impersonation. User instances should not be used for third-party or shared hosting scenarios where all applications would share the same user instance and would no longer remain isolated from each other.
Will this work right away without any extra configuration? When I try to add a DB to every successive application, I get a file in use error if anything else is using the DB which leads me to believe that I can't do it this way. However, if I stop the DB from being used, then add it, and then start it up, it seems to work fine. Does anyone have any reassurance for me that it won't be corrupted or experience any errors by using it this way?
Preferably, the mdf & ldf would be stored in the Web Site's App_Data directory (|DataDirectory|). If I do it this way, I don't think I can reliably use relative addressing for the Service unless I put it in a sub directory for the Site, is this correct?
edit: I'm using SQL Server Express because this is an assignment for school, so I pretty much have to use it. If there is a way without User Instance I'll try to do without it.
You can't use User Instance for this. This allows just one client at a time to connect to your database. When your two applications use the same credentials, you get the error you describe. When your two applications use different credentials, you essentially get two separate instances (also not what you want).
Besides, user instances are only supported on SQL Server Express. I don't know what your production environment looks like, but it probably does not run on SQL Server Express?
You should use AttachDBFilename in the connection string of your web application to point to the local database: AttachDBFilename=|DataDirectory|\MyDB.mdf.
In your web service you also use AttachDBFilename but it depends on the deployment location of the web service where to point it to.

ASP.NET Development Server or Localhost IIS?

Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.

Resources