Archive for the 'Powershell' Category

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.

Addressing the PowerShell Script Error for AuthorizationManager check failed

Published October 21, 2011 Powershell , Windows Server 2008 , Windows Server 2008 R2 , Security 1 Comment
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

PowerShell Errors Connecting to Active Directory Domains and Forests

Published October 13, 2011 Active Directory , Microsoft Active Directory , Powershell Leave a Comment
Tags: , , , , , , ,

I needed to work with data from a child domain in our test environment so I tried to access the child domain using the Get-ADDomain cmdlet from the Active Directory module for PowerShell. When that operation failed, I attempted to map a PS drive to the child domain instead, but this operation failed as well. However, both the Get-ADDomain and New-PSDrive cmdlets work fine in the root domain of the forest.

I noted the following errors messages with each cmdlet and the New-PSDrive error message holds the key to solving the problem.

Get-ADDomain : Cannot find an object with identity: ‘child.root.local’ under: ‘DC=root,DC=local’.

New-PSDrive : Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running.

Resolution

The New-PSDrive error message best exposes the source of the problem. I know the server and domain exist so that’s not the problem. Instead, the Active Directory module cmdlets cannot contact the domain because it does not have at least one Windows Server 2008 R2 domain controller in the domain or at least one instance in an AD LDS configuration set that is running on a Windows Server 2008 R2 server.

Aha! My child domain does not have any Server 2008 R2 DCs or LDS instances. So how can I address this? There are a few options.

  1. Install the Active Directory Management Gateway Service on at least one non-2008 R2 domain controller, including Server 2003 and 2008. This provides a Web service interface to Active Directory domains and instances of Active Directory Lightweight Directory Services (AD LDS) or Active Directory Application Mode (ADAM) that are running on the same server as the Active Directory Management Gateway Service.
  2. Promote an existing Server 2008 R2 member server in the domain to a domain controller.
  3. Upgrade at least one DC in the domain to Server 2008 R2.

Routing PowerShell Command Results to the Write-Output Cmdlet

Published October 6, 2011 Powershell Leave a Comment
Tags: , , ,

I am working on a project where we host a PowerShell runspace in IIS and I needed to dump some output from a command using the Write-Output cmdlet. I futzed around for a while trying to execute a command in the middle of the Write-Output parameter something like what follows. This is my attempt to output the current working directory using a script block but it does not work because everything in quotes is taken as a string literal since the & character isn’t at the beginning of the line.


Write-Output "Current directory is { & pwd }"

I found a better way to do this by piping the output of the pwd command to the Write-Output cmdlet. This works well and gets me the output I need.


pwd | Write-Output

I may try to concatenate a string with the output so I can produce something like “Current directory is C:\Program Files\…” but this approach takes care of the most important need. I will update this post with any further details and feel free to comment if you have a different approach to this situation.

Using the PowerShell Get-ADDomain cmdlet with an IIS Application Pool Identity

Published August 10, 2011 .NET , .NET , ASP.NET , Development , IIS , Powershell Leave a Comment
Tags: , ,

We use the PowerShell Active Directory module cmdlets for our applications and wanted to share a tip if you’re running the Get-ADDomain cmdlet using the default IIS application pool identity. Since this identity is actually a Windows Virtual Account, you cannot get to a domain using Get-ADDomain based on the application identity since there is no IIS AppPool domain in AD. You will see an error like the following with the default behavior.

Get-ADDomain : Cannot find an object with identity: 'IIS APPPOOL' under: 'DC=example,DC=local'

Use the local computer for the current scope and the Get-ADDomain cmdlet will work properly by using the current computer’s domain.

Get-ADDomain -Current LocalComputer

PowerShell Hosting in ASP.NET: Resolving Errors with PowerShell Set-ExecutionPolicy

Published August 8, 2011 .NET , .NET , ASP.NET , IIS , Powershell , Windows 7 , Windows Server 2008 , Windows Server 2008 R2 1 Comment
Tags: , , ,

One of the great innovations in Windows PowerShell is the ability to host the PowerShell run-time environment in any number of run-time hosts. We use this capability to host PowerShell in an ASP.NET web application process for our PeopleProvision solution. Everything works great once you get over a couple of big security hurdles.

  1. File SomePowerShellFile.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.
  2. Access to the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’ is denied.

Many sources on the web document exactly what is going on with these error messages. Basically, Microsoft architected PowerShell and Windows Server 2008 R2 so the operating environment is protected from unauthorized PowerShell script execution. This is a good thing. However, it’s not so good when you need to run your own PowerShell script in a host other than the standard PowerShell command shell. You can’t just right-click and choose Run as administrator when your PowerShell host environment doesn’t have a GUI. In a scenario where you host PowerShell in an ASP.NET process, how do you get around this?

It turns out that you can securely run scripts on your system by changing the PowerShell execution policy. In your script, include a command to set the execution policy to an acceptable level for your needs. For example, the command below allows local scripts and signed scripts from the Internet (RemoteSigned policy) to run only in the current PowerShell process (Process scope). This is a great way to run your trusted scripts in an ASP.NET process without opening up tons of security holes.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

After you add this to your script, save the script and then try to run your ASP.NET application. If you see the following error then you might need to restart IIS (or at least unload the application pool by stopping and starting the web site) to get your changes to take effect.

Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied.

That should be all you need to safely execute your PowerShell scripts from an IIS application pool. Check out the PowerShell Set-ExecutionPolicy cmdlet documentation for more options to set the appropriate PowerShell execution policy for your needs.

Active Directory Provisioning with PowerShell: Extensibility and Power without Costly Implementation (Part 3 of 4)

Published August 4, 2011 Active Directory , Active Directory Users and Computers (ADUC) , Business Philosophy , Exchange , Microsoft Active Directory , PeopleProvision , Powershell , SQL Server , User Experience , Windows Server 2008 R2 3 Comments
Tags: , , ,

This is Part 3 of Web Active Directory’s blog post series highlighting our new PowerShell-enabled platform. We introduced the series with an exam of how other software vendors approach provisioning with costly implementation services and then looked at WebAD’s PeopleProvision solution more closely.

In this post, we look at how easy it is to implement PeopleProvision to help delegate and automate the Active Directory and Exchange mailbox provisioning processes. The final post in our series shows how leveraging PowerShell for easy customization and extensibility allows you to easily model your business logic using a well-known, proven technology platform.

Implementation services can generate a lot of dollars for software companies and many software vendors rely on these services as a key revenue stream. Since companies earn revenue from implementation services, the companies are incented to maximize the money they earn while implementing their software products and the cost for implementation often goes sky high, even approaching the cost of the software itself.

Web Active Directory takes a different approach to implementation services. Throughout our history, we’ve focused on producing useful software that installs quickly and easily without requiring implementation services. Now that we’ve crossed the road into provisioning with the PeopleProvision solution, we plan to preserve the goal of emphasizing software usage over implementation services. PeopleProvision takes less than 30 minutes to install and just an hour or two to configure (after pre-requisites are installed, of course) and we help you with this process.

Better yet, the out-of-the-box PeopleProvision functionality—AD account creation, Exchange mailbox creation, home share creation and mapping, address and organizational AD attribute data population—enables many organizations to get up and running merely by creating a few provisioning rules. Your organization can have a fully-functional AD/Exchange provisioning implementation running in only a few hours!

We do see more complex scenarios where organizations require custom business rules processing when creating new AD accounts and Exchange mailboxes. In these cases, we work with you to analyze your needs and provide a full scope of work before moving forward. This means you know exactly what we’re going to do and how much it will cost so you can decide how to proceed. No long, costly implementation engagements for weeks at a time…just a simple, straightforward bid for only the work you need to get up and running for your custom needs.

Best of all, you can do all your customizations yourself with no implementation services from WebAD since we provide the PowerShell script source code to you. This allows your organization to leverage its PowerShell expertise and save some cash along the way.

We present the final post in our blog series tomorrow where we’ll check out how PowerShell empowers PeopleProvision to go way beyond out-of-the-box provisioning and really energize your organization’s provisioning processes.

Active Directory Provisioning with PowerShell: Extensibility and Power without Costly Implementation (Part 2 of 4)

Published August 3, 2011 .NET , Active Directory , Active Directory Users and Computers (ADUC) , Business Philosophy , Exchange , Microsoft Active Directory , PeopleProvision , Powershell , SQL 2008 , SQL Server , User Experience , Windows Server 2008 R2 3 Comments
Tags: , , ,

We are taking a look at Web Active Directory’s new PowerShell-enabled platform this week in a series of blog posts. We introduced the series by discussing how many software companies like to squeeze every red cent from their customers by using proprietary technologies that require costly implementation services.

This post introduces WebAD’s PeopleProvision tool to help delegate and automate the Active Directory and Exchange mailbox provisioning processes without requiring complicated implementations or extensive training. The next two posts in the series examine the keys to a quick PeopleProvision implementation and finally—perhaps most important of all—the benefits of exposing business logic in PowerShell for easy customization and extensibility without requiring extensive consulting services.

WebAD introduced PeopleProvision earlier this summer to make it simple and affordable to implement a custom provisioning tool for creating Active Directory accounts and Exchange mailboxes. There are a number of solutions of varying capabilities and price on the market today but our customers kept telling us something was missing. After analysis of the current IdM provisioning playing field, we introduced our PeopleProvision solution with three main goals.

  1. Deliver a solution that doesn’t blow your budget out of the water.
  2. Enforce best practices in provisioning through application design while keeping the application itself very simple to use and administer.
  3. Allow powerful extensibility and customizations using well-known, proven technologies.

With these goals in mind, we spent a significant amount of time analyzing the key activities in most common provisioning processes. This analysis garnered three main pieces of information that determine most AD attribute values for new accounts and PeopleProvision uses this information to help drive the information populated in Active Directory and Exchange when creating accounts and mailboxes.

  1. Office location: Address information as well as distribution and security group membership
  2. Department: Organization information as well as distribution and security group membership
  3. Job title: Very targeted distribution and security group membership

Once we had a feel for the provisioning activities, we began to develop a design approach that puts the users first—both end-users and system administrators—to make the application easy to use and intuitive to administer. This design approach allowed us to produce a simple and elegant user experience that emphasizes form and functionality.

Simple Design Philosophy for PeopleProvision v1.0

PeopleProvision v1.0 UX Design

This simple 10-field form collects all the information necessary to create a new Active Directory user account and Exchange mailbox with the following features.

  • Full attribute population including address, telephones, organization, manager, email address and unique account name
  • Custom profile settings including profile directory path, login script and a mapped user home drive with the user share already created and NTFS permissions applied
  • Group memberships including security and distribution groups
  • Exchange mailbox creation on the correct database with proper limits applied

PeopleProvision can do all this work based on 10 fields or fewer because it understands the key pieces of information along with the rules needed to process that information. The customizable form gathers the key information using a simple interface that enforces data integrity while providing help documentation directly on the page. Check out our PeopleProvision videos to see how easy it is to create a new user and administer provisioning rules used to create AD accounts and Exchange mailboxes.

Tomorrow we’ll look at the simple implementation process that WebAD uses to get PeopleProvision up and running in your environment. And then the fun begins with an examination of how PowerShell really gets the PeopleProvision engine going in the final post of the series.

Active Directory Provisioning with PowerShell: Extensibility and Power without Costly Implementation (Part 1 of 4)

Published August 2, 2011 Active Directory , Exchange , Microsoft , Microsoft Active Directory , PeopleProvision , Powershell 3 Comments
Tags: , , , , , , , , , , , , , ,

Too often, software companies want absolute control of their black box of intellectual property (IP). These companies only want extensibility and customizability if it means more revenue from implementation services. A few companies in our space have even developed their own scripting languages to make customers pay for more services or training to learn yet another proprietary language technology.

We take a much different approach in our software efforts. Our new platform leverages Microsoft’s PowerShell technology to empower system engineers and administrators to extend applications using technology they already understand. We want to keep our solutions easy to deploy, a cinch to maintain and a snap to extend to meet new and ever-changing business needs. While other software companies catch the fish for you and then sell them at a costly markup we prefer to teach you to fish using a platform that you know and use on a regular basis.

PeopleProvision—WebAD’s first application built on our new PowerShell-enabled platform—allows you to delegate and automate Active Directory account and Exchange mailbox creation. PowerShell provides the heavy lifting and you get the benefit of access to the PowerShell source code so you can extend PeopleProvision’s behavior to meet the business requirements of your organization.

Over the next three blog posts, we will examine how PeopleProvision and its accompanying PowerShell toolkit empower you to take control of your provisioning and de-provisioning processes with a minimum of costly software licensing and implementation costs. We look at the PeopleProvision solution itself in more detail in Part 2 tomorrow and then delve into the secrets of a small implementation in Part 3 the next day. Finally, we teach you to fish in Part 4 by linking the PowerShell specifics to the PeopleProvision front end.

Join us for our journey through PeopleProvision and learn how you can automate and delegate your account provisioning and de-provisioning at an affordable cost of money, time and effort.

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 243 other followers

Web Active Directory Products

Download PDF product data sheets:
Follow

Get every new post delivered to your Inbox.

Join 243 other followers