How to find the IUSR password and IWAM password in IIS

If you allow anonymous users to access your Web site, they'll be accessing your computer using the built-in IUSR_computername account that is created automatically by IIS.

Processes initiated by IIS run on your machine using the built-in IWAM_computername account, also created automatically by IIS.

This is all configurable -- you can configure IIS to use other accounts for anonymous access, and for processes. But by default, these are the ones that get used.

Here is how to find out the passwords for the IUSR or IWAM accounts:

1. Navigate to C:\Inetpub\AdminScripts

2. Edit the file called adsutil.vbs

3. Scroll down almost to the bottom, to where it says

If (Attribute = True) Then

IsSecureProperty = True

Else

IsSecureProperty = False

End If

4. On the first condition, change True to False, like this

5. Save the change.

6. Now that you have modified the script, you can run a couple of commands to discover the IUSR and IWAM passwords. Open a command window. To see the IUSR password, run this command:

cscript.exe c:\inetpub\adminscripts\adsutil.vbs get w3svc/wamuserpass

To see the IWAM password, run this command:

cscript.exe c:\inetpub\adminscripts\adsutil.vbs get w3svc/anonymoususerpass

The output will be in double quotes. The double quotes are not part of the password.

7. Once you've retrieved your passwords, edit adsutil.vbs again and change False back to True. You don't want someone with malicious intent to learn these passwords.

Where are LogFiles for IIS 7?

Last Thursday I was dealing with a web app that wouldn't work on a computer running Vista. I needed to check the IIS log file, so I went where I always go -- to

C:\Windows\System32\LogFiles. But there was no LogFiles folder. There was HTTPERR, and some unfamiliar folders, but no LogFiles.

Turns out that for IIS7, log files don't live there any more. They have moved to C:\Inetpub\LogFiles.

I didn't check my 2008 Server, but I suppose that will be true for IIS version 7 there, also.

How to save YouTube videos

A real person asked, "How do I download clips from YouTube to my computer?"

There are sites where you can paste in the URL from YouTube, and then download the file. I use this one:

http://www.videodownloadx.com/

Steps:

1. In the download field, paste the full URL from YouTube. For example, http://www.youtube.com/watch?v=abrKM1Z_te8

2. Click the Download Video button.

3. Notice the screen re-displays. Scroll down a bit if necessary, and on the left beside the Ads by Yahoo you will see a small image of your video. In between the ads there's some text that looks like this:

>> Download Convert Record Stream<<

4. In this text, click on the word Download.

5. When prompted, choose to save the file.

6. In the Save As dialog (or equivalent if you're not on Windows or not using Internet Explorer), replace all the text in the File Name field with a meaningful file name that has .flv as the file type. For example, Californication.flv.

7. Click Save (or equivalent) to save the file.

Thing is, the file you download will be a .flv file, and you will need a special player to play it. I use the one that comes up when you google the term "flv player". It's a link to freeware downloadable from CNET's download site. Right now, that link is

http://www.download.com/FLV-Player/3000-13632_4-10896762.html

Download and install that player, which is free, and you will be able to play the FLV files you download.

Hope this helps!

The procedure entry point ?SQLUIUpdateRegistryFromResource@@YAJHPAUHINSTANCE__@@IKPAPBG1@Z could not be located in the dynamic link library SQLRESLD.dll.

Had a customer the other day who was installing an app on Windows 2000 Professional. We don't see Windows 2000 much any more, even 2000 Server. Anyway, this particular machine had been around for years, and had a lot of old apps installed on it, including Microsoft SQL Server version 7.

Whenever the customer would launch our app, he'd get this error:

The procedure entry point ?SQLUIUpdateRegistryFromResource@@YAJHPAUHINSTANCE__@@IKPAPBG1@Z could not be located in the dynamic link library SQLRESLD.dll.

Then he'd click OK, and he'd get this error:

System.Runtime.InteropServices.COMException (0x8007007F): Retrieving the COM class factory for component with CLSID {10020200-E260-11CF-AE68-00AA004A34D5} FAILED DUE TO THE FOLLOWING ERROR: 8007007F.

This second error was recognizable - that's the class ID for SQL-DMO, which the app uses to communicate with SQL Server. We see that 0x8007007F error for that class ID all the time, on machines where SQL-DMO is not registered.

The usual solution is to go find SQLDMO.DLL in C:\Program Files\Microsoft SQL Server\80\Tools\Binn, and register it using regsvr32.exe. Or, sometimes we throw a copy of SQLDMO.DLL and SQLDMO.RLL in our own app folder, and register it there, just to get by.

(A quick note about registering DLLs: you can bring up a command window and navigate to the folder where the DLL resides, and then run regsvr32.exe sqldmo.dll, for example. But most of the time, I right-click on the DLL and choose Open With, and browse to regsvr32.exe in C:\Windows\System32, and make a permanent file type association. That way, from then on I can register any DLL just by double-clicking it. If I get an error that the DllRegisterServer entry point can't be found, then I know it didn't need registering in the first place.)

Back to the IKPAPBG1 issue. we tried to register SQL-DMO, and that failed. I don't have the error handy, but the gist of it was that some RLL couldn't be found at C:\Resources\1033. For this, we tried brute force, and copied

C:\Program Files\Microsoft SQL Server\MSSQL$INSTANCENAME\Binn\Resources\1033

to

C:\Resources\1033.

Not the "right" solution, but worth trying to see if it would get us up and running.

Tried to register SQLDMO.DLL again, and this time, the error thrown by regsvr32 was

C:\Program Files\Microsoft SQL Server\MSSQL$INSTANCENAME\Binn\sqlresld.dll
was loaded, but the DllUnregisterServer entry point was not found.

DllUnregisterserver may not be exported, or a corrupt version of C:\Program Files\Microsoft SQL Server\MSSQL$HDBID\Binn\sqlresld.dll may be in memory. Consider using PView to detect and remove it.

By this time, all the errors together were beginning point to a versioning problem. As if, for some reason, version 7 DLLs were being accessed instead of version 8 (2000). What would make that happen?

In Add/Remove programs, we could see that MSSQL 7 was still installed, although it wasn't running. We checked the Path environment variable, and noticed that C:\MSSQL7 was near the front of the list.

We considered removing it from the Path, since it wasn't in use, but decided instead to try renaming the C:\MSSQL7 folder so it wouldn't interfere. And that did the trick. We ran regsvr32.exe sqldmo.dll, and it worked, and we launched the app, and it worked too.

Solved. If this story helps you, post a comment and let me know!

Unable to open the physical file "C:\MyDatabase.mdf". Operating system error 5: "5(Access is denied.)"

One of the applications I test frequently detaches and re-attaches SQL Server databases. The app manages hundreds of databases all with identical schema, detachable for portability and ease of copying.

Originally the app only worked with SQL Server 2000 (or MSDE), but after SQL Server 2005 (SQL Express) had been available for a while, we decided to support it too. It turned out to be harder than we expected, because every time we detached a database, we were unable to attach it later.

The errors looked like this:

Unable to open the physical file "C:\MyDatabase.mdf". Operating system error 5: "5(Access is denied.)"

Turns out that SQL Server 2005, in order to better secure the data inside an MDF file, automatically resets file permissions whenever the MDF is detached. I got no problem with that -- it makes sense, when you think about how before, your data was always securable as long as you were accessing it through the SQL Server engine, but if you forgot to secure your MDFs and LDFs, anyone who got their hands on those could probably get whatever information they wanted out of them.

Just, for our app, it made life crazy. Permissions would get reset so that only the person who did the detach could re-attach. Or sometimes, a process running as a service under the Local System account would detach, and then nobody could manually re-attach.

Luckily, after a lot of research that took way too long, we discovered trace flag 1802. Trace flag 1802 turns off the permission-resetting behavior. This particular trace flag needs to be set in the startup properties for the instance, so that it is always in effect. If you set it dynamically using DBCC TRACEON, it won't stick through the next time you restart your instance.

To enable trace flag 1802:

1. Start > Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Configuration Manager

2. In the tree list on the left, click on SQL Server 2005 Services

3. On the right, right-click your SQL Server instance name, and choose Properties

4. In the Properties dialog, click on the Advanced tab

5. Find the property called Startup Parameters. There is a long string of parameters in this field. Click the dropdown arrow to view and edit the string.

6. At the end of the string, add ;-T1802