Archive for the 'Windows Server 2008 R2' Category

ASP.NET 4.0 Error: Could not load file or assembly ‘Some.dll’ or one of its dependencies. An attempt was made to load a program with an incorrect format.

Published February 20, 2012 .NET , .NET , ASP.NET , IIS , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , , , ,

I was testing an ASP.NET application installation on a test server recently and ran into the following error when I ran the application.

Could not load file or assembly 'Some.dll'' or one of its dependencies. An attempt was made to load a program with an incorrect format.

I hadn’t seen this during development on my local machine and a quick bit of searching led to an answer. I have a 32-bit development machine and I was testing on a 64-bit platform.  In IIS 7 and later, ASP.NET 4.0 application pools don’t allow 32-bit applications by default when using an installer like we use. A simple flip of the Enable 32-bit Applications flag in the Advanced Settings of the application pool configuration did the trick to let things run fine and dandy.

Check out the screenshots for a little more guidance and thanks to this post for some guidance. Just make sure to set the Enable 32-bit Applications option to True and you should be ready to go.

IIS Application Pool Advanced Configuration: Enable 32-bit Applications

IIS Application Pool Advanced Configuration

Active Directory Management Gateway Service (ADMGS) Errors and McAfee Anti-Virus Software

Published January 20, 2012 Active Directory , Active Directory Management Gateway Service , Microsoft Active Directory , PeopleProvision , Powershell , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , ,

I posted last month about an issue with the Active Directory Management Gateway Service (ADMGS) on Windows Server 2008. The ADMGS  (which runs as the Active Directory Web Services, ADWS, service) allows you to use the Active Directory module for Windows PowerShell to manage AD remotely in domains where there are no Server 2008 R2 domain controllers running.

I saw the following error messages when running the “import-module activedirectory” command in PowerShell.

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

I was able to diagnose the ultimate cause based on my previous post but still was receiving errors even after mucking with NTFS directory permissions for temporary .NET files. I finally had the idea to check on anti-virus software to see if that was blocking the communication. Wallah! The domain controller had anti-virus software installed (in this case it was McAfee) and as soon as I adjusted the AV software configuration the AD connection was allowed. The log entries below help pinpoint the cause.

1/19/2012        5:22:05 PM        Blocked by Access Protection rule         NT AUTHORITY\SYSTEM        C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe        C:\Windows\TEMP\t0sggpq5.dll        Common Maximum Protection:Prevent creation of new executable files in the Windows folder        Action blocked : Create

1/19/2012        5:22:07 PM        Would be blocked by Access Protection rule  (rule is currently not enforced)         NT_DOMAIN\SRS-RMRES2-02$        System:Remote        C:\Windows\SYSVOL\domain\Policies\{1C9122E4-78CD-4001-A2E7-8BBCA348C893}\GPT.INI        Anti-virus Outbreak Control:Block read and write access to all shares        Action blocked : Read

So make sure to check your AV software if you have this kind of problem…it just might be the key to a solution!

Diagnose Active Directory Management Gateway Service (ADMGS) Errors

Published December 15, 2011 Active Directory , Active Directory Management Gateway Service , Microsoft Active Directory , PeopleProvision , Powershell , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , ,

I recently worked on a Windows Server 2008 system with the Active Directory Management Gateway Service (ADMGS) installed. The ADMGS allows you to use the Active Directory module for Windows PowerShell to manage AD remotely in domains where there are no Server 2008 R2 domain controllers running.

The ADMGS service (which runs as the Active Directory Web Services, ADWS, service) worked fine for several months but decided to begin having problems recently. We saw the following error message when running the “import-module activedirectory” command in PowerShell

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Needing to troubleshoot the source of the issue, I messed with the IncludeExceptionDetailInFaults attribute in the C:\Windows\ADWS\Microsoft.ActiveDirectory.WebServices.exe.config file. However, this proved to be a daunting task for a number of reasons so I moved on to another solution. (View an example of setting the IncludeExceptionDetailInFaults attribute.)

Finally, I located a post that helped break this open. Adding a couple of debug keys in the <AppSettings> section of the config file allowed me to log the ADMGS error on the server and diagnose the real source of the error.

<add key="DebugLevel" value="Info" />
<add key="DebugLogFile" value="C:\Windows\Debug\adws.log" />

Use the following valid string values (not numeric values) for the DebugLevel value.This will add diagnostic info into the debug log at the DebugLogFile path you specify.

  • 0 – No logging
  • 1 – Error (this logs critical errors only)
  • 2 – Warn (this logs warning events as well as error events) – Recommended value to use unless you need full tracing
  • 3 – Info (verbose)

Once I set up debugging and restarted the ADMGS service, I got to the bottom of the problem with the error below and I can now address the permissions issue that is causing connection problems with the “import-module activedirectory” PowerShell command.

ActiveDirectoryWebServices: [xx/xx/2011 6:14:15 PM] [3] Get: Unhandled Exception System.UnauthorizedAccessException: Access to the temp directory is denied. Identity 'YOUR_DOMAIN\YourAccount' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.

Edit 64-bit File with a 32-bit Editor on Windows 2008 64 or R2

Published October 31, 2011 Windows Explorer , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , ,

I worked recently on a project where I needed to make a change to an IIS 7.5 configuration file on Windows Server 2008 R2. While trying to edit the file, I kept getting an error message trying to use my default text editor, TextPad.

C:\Windows\System32\inetsrv\config\administration.config was not found.
File Not Found

File Not Found

I also noticed that Windows Explorer rendered the files on the file system with some strange lock icons I don’t recall seeing before.

Strange File Lock Icons

Strange File Lock Icons

After several attempts to open the files for editing in TextPad, I began searching the interwebs looking for an answer and stumbled across a post that helped me break through. Rick Strahl mentions an issue using a 32-bit application to edit certain files in the System32 folder.

Since all Server 2008 R2 flavors run as a 64-bit OS, I decided to try using the native Notepad installation instead of my 32-bit TextPad editor. Wallah! The file opened just fine and I was able to make my changes and move along once I got past the annoyances of Notepad…but I digress. ;-)

So remember that if you see a strange lock icon or you try to use a 32-bit editor to open files on a 64-bit platform, things may not work out. Try opening the file in Notepad to see if that will work to get you by while you get a 64-bit editor installed.

Addressing the PowerShell Script Error for AuthorizationManager check failed

Published October 21, 2011 Powershell , Security , Windows Server 2008 , Windows Server 2008 R2 2 Comments
Tags: , , , , , , , ,

I was recently working in a client environment and running a PowerShell script that calls a bunch of other scripts on the file system using the dot sourcing technique. The scripts run fine in a number of other customer environments as well as our test environment but I kept seeing an “AuthorizationManager check failed” when several scripts were called from the main script.

I messed around with permissions for while and then drank a few beers to see if things with PowerShell were now better. The PowerShell wasn’t better but I felt okay with the addition of the beers. I still needed to find a solution, though, and decided to approach this fresh after a few days (and possibly more beers!).

With a fresh approach, I found a simple post that sprung the entire solution for me. I had used Internet Explorer (I know, I know…I was on a Windows Server 2008 R2 box in a customer environment…not much choice there) to pull down a few PowerShell files over HTTP from our website. Guess which files I pulled down using IE. Yep! You betcha…the very script files that all failed when the AuthorizationManager calls ran! Needless to say, you should unblock PowerShell script files downloaded using IE, even if they’re from your own web site!

The key is to unblock files that you’ve downloaded so PowerShell will run them!

Check out the screen shot below to make the simple unblock from the PowerShell script file properties. Just right-click the file and choose Properties from the context menu.

Windows File Properties - Unblock File

Windows File Properties - Unblock File

Active Directory Attributes for Remote Desktop Services

Published October 5, 2011 .NET , Active Directory , Microsoft Active Directory , Remote Desktop Services , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , ,

We are working with a customer who needs to set some values for the Remote Desktop Services (RDS) Profile (formerly Terminal Services) attributes in Active Directory. Even after working with AD and programming for it for more than 10 years, I’ve never had the need to access these attributes until now. Easy enough, right? We’ll just look up the attributes in the AD schema and be off and running.

Alas, it’s not that easy to set the Remote Desktop Services Profile attribute values in AD. All RDS parameters are stored in a BLOB (binary large object) in the Active Directory userParameters attribute. If you want to interact with this value directly through LDAP, you must decode and encode the attribute value to access the individual BLOB members that represent the values for the RDS Profile attributes. The encoding algorithm is a bit strange, though, and poorly documented. I found a fairly clear and precise reference for the BLOB encoding algorithm (ironically, for use by a Linux admin) and you can give it a try but there is a better option to interact with RDS profile attribute values if you have access to the COM API.

An article by Alejandro Campos Magencio does a nice job of spelling out the technical details needed to properly implement reading and writing RDS Profile attributes in AD. Microsoft added AD schema extensions in Server 2008 to support this need with the msTSProfilePath, msTSHomeDrive and msTSHomeDirectory attributes. At this point, though, these attributes aren’t being used and you still must rely upon the userParameters BLOB. The Tsuserex.dll library provides an ADSI (Active Directory Service Interfaces) extension that allows you to work with RDS profile values through the IADsTSUserEx interface. The interface implements properties including TerminalServicesHomeDirectory, TerminalServicesHomeDrive and TerminalServicesProfilePath that allow you to read and modify RSD profile values in the userParameters BLOB.

This should help you get started with an implementation. I will explore this subject more in a later post and provide some PowerShell and C# code to help illustrate how to read and write RDS profile attributes in AD.

A Workaround in IIS 7 for the “User Must Change Password at Next Logon” Flag in Active Directory

Published September 30, 2011 HTML , IIS , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 1 Comment
Tags: , , , , , ,

In yesterday’s post we looked at an issue with the IIS 7 architecture where Windows and Basic authentication fail when the “User must change password at next logon” flag is set for an Active Directory user. Microsoft engineered IIS 7 to deny access to users who have this flag set. This change from previous versions of IIS causes problems when you want to use tools like IISADMPWD to allow web application users to change their Active Directory password.

Web Active Directory looked at this situation and created a solution that allows you to bypass the issue in IIS 7. Understanding that the problem stems from the fact that IIS 7 denies access to users who need to change their password at the next logon, we took an approach to use Anonymous authentication in IIS  and avoid the denial issue.

The small web application we produced provides a logon screen and then checks the status of the “User must change password at next logon” flag before performing authentication against Active Directory. This allows you to provide a customizable logon form with instructions and your own branding instead of using the default browser pop-up dialog.

Best of all, if the user needs to change her password you can route the web application to the IISADMPWD replacement web app we also created. If the user does not have to change her password and the credentials check out, the application passes the authentication credentials down the way and everything proceeds as normal.

Contact Web Active Directory for more information about this solution and the IISADMPWD replacement tool for IIS 7.

A Replacement for IISADMPWD in IIS 7

Published September 29, 2011 Active Directory , IIS , Tools , Windows Server 2008 , Windows Server 2008 R2 2 Comments
Tags: , , , , , , , ,

Many organizations have employed Microsoft’s IISADMPWD tool to allow password changes in Active Directory for web applications. Originally intended as the way to change passwords for access in Outlook Web Access (OWA), IISADMPWD became quite a useful solution for any organization that wanted to delegate access to AD password changes via a web application.

With the release of IIS 7 and its architectural and security changes from previous versions of IIS, there are certain situations where the old IISADMPWD will not work. In fact, Microsoft doesn’t even support IISADMPWD on IIS 7 and later although some organizations have been able to deploy it in an unsupported fashion.

The main situation where IIS 7 behaves differently from previous versions of IIS is when a user needs to change her password and the “User must change password at next logon” flag is set in Active Directory. In this situation, we’ve not found a way to authenticate a user with either Windows or Basic authentication in IIS and the old IISADMPWD tool cannot meet the requirements to allow the password change for users with this flag set. This is problematic since the scenario where a user needs to change her password after an administrative reset is very common.

Web Active Directory has developed a replacement for IISADMPWD that uses anonymous authentication to work around the IIS 7 authentication issue when the ”User must change password at next logon” flag is set for a user. Tomorrow we will take a closer look at the architectural approach and a new tool that WebAD developed to help in this scenario.

Contact Web Active Directory for more information about the IISADMPWD replacement tool for IIS 7.

Adding Windows Computer Accounts from Active Directory to NTFS ACLs to Control Permissions

Published September 2, 2011 Active Directory , Development , IIS , Microsoft Active Directory , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , , , , , , ,

When writing web applications, you often must grant permissions to an application to do something on other machines in a Windows domain or forest. IIS 6, 7 and 7.5 all allow you to configure IIS application pools to run under specific, rather secure identities like NETWORK SERVICE and the Application Pool Identity.

When accessing resources over the network using these identities, remember one simple rule: You must ensure to search computer accounts in Active Directory when granting access to a resource. We commonly add a computer account to an NTFS ACL to allow a web application to create directories on a remote machine. Computer accounts take the form of <DomainName>\<ComputerName>$ when accessing resources over the network and make sure you include the dollar sign ($) on the end of the computer name.

Tip

When locating the security principal (account) to add to the ACL, make sure you search computers in addition to the standard users, groups and built-in security principals. If you don’t do this you will pull your hair out trying to figure out why Active Directory can’t resolve your computer account name and let you assign permissions.

The following screen shots illustrate the bad and the good on Windows Server 2008 R2 for adding a security principal to a NTFS ACL.

The BAD

This will drive you nuts because AD can’t resolve the computer account name. Why? Because you’re not searching computers…only users, groups and built-in security principals.

Computer Name Resolution Failed

Cannot resolve the computer name because AD is not searching computer objects

The GOOD

Mucho better when we add computers to the object types to search!

Computer Name Lookup

Change the Object Types to include computers

Now you’re in business!

Computer Name Resolution Success

Computer account resolves now!

Run IIS Web Applications on a Windows Member Server and Not a Domain Controller

Published August 17, 2011 Active Directory , DNS Server , Exchange , IIS , Microsoft Active Directory , SQL 2008 , SQL Server , Virtualization , VMWare , Windows Server 2008 , Windows Server 2008 R2 Leave a Comment
Tags: , , , , , , , , ,

Most of our software products run on Microsoft’s IIS web server. In our product installation guides, we specify in the system requirements to install our web applications on a member server instead of a domain controller. Recently, a prospect asked us why we recommend this since WebAD products connect to Active Directory. Is it really a best practice to use a Windows member server instead of a domain controller to run IIS web applications and other services like SQL Server or Exchange?

In short, it’s best to run web applications and other functional roles on a member server instead of a domain controller. Yes, Microsoft does have offerings like Windows Small Business Server (SBS) that combine seemingly myriad roles on a single server but these scenarios are really only intended for small businesses with simple needs. For many organizations, separating domain controller functions from member servers running other services allows you to maintain the health of your Active Directory environment without interference from oddities brought on through other services and applications. You can still combine roles on member servers to share hardware and software resources but there is no need to clutter your DC with unnecessary services that might interfere with AD operations.

The following snippet from an excellent discussion at ServerFault provides great insight.

“Splitting out your server roles to separate boxes does put you in a very nice position where you can do maintenance on one box without affecting the others. Also, putting weird and flaky third party software (I’m talking printer drivers here) on a DC doesn’t chime well with my sensibilities. Thirdly, you want your DC event logs to be squeaky clean, you don’t want a minor heart attack any time you get a security or system warning from one of those!”

Another great comment from the same discussion provides more fodder to separating domain controller functions from other roles and services, although there are a few roles like DHCP and DNS that can work quite well on a domain controller.

“Multi-Role Domain controllers are pretty common. Although, most roles they perform are network infrastructure roles. Good examples are File Servers, DHCP and DNS. They are poor choices for things like Terminal servers (Users do not have rights to log into a Domain Controller and giving them said rights grants requires Domain Admins), Web Application Servers, Line of Business App Servers, Firewall/Proxy/ISA servers, etc. In my environments, I prefer to have all internal DNS Servers running on Domain Controllers as well as my DHCP services. This seems to be a good mix of roles on the DCs to reduce cost and make the best use of the hardware possible.”

With the advent of virtualization, the need to combine roles on domain controllers really goes away since the cost to spin up a new virtual machine instance is very cheap. Make it easy on yourself and keep your domain controllers pure while combining roles and services on member servers.

Next Page »

Slipstick Systems Outlook and Exchange Solutions Center
Utilities, how to's and other solutions for Microsoft Outlook and Microsoft Exchange users, administrators and developers

Share this blog

Facebook Twitter More...

Enter your email address to subscribe to WebActiveDirectory blog via email.

Join 33 other followers

Web Active Directory Products

Download PDF product data sheets: