I'm new to powershell, but I recently setup a Powershell Web Access Server following this guide (http://blogs.technet.com/b/canitpro/archive/2013/11/14/step-by-step-deploy-powershell-web-access.aspx). On that server (running 2012 R2) I installed RSAT for AD with Powershell and Exchange Powershell. When I use PSWA to connect to the same server that it is hosted on and run "Import-Module ActiveDirectory" It gives me this error

WARNING: Error initializing default drive: '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.'.

It lets me go on to run "Get-ADUser"

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.    
+ CategoryInfo          : ResourceUnavailable: (bob.smith:ADUser) [Get-ADUser], 
ADServerDownException     + FullyQualifiedErrorId : 
ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADUser 

If I use PSWA to connect to the domain controller instead of the shell server itself, I can run these commands just fine. I can also run these commands fine if I remote desktop into the shell server and run powershell there. My goal however is to create something of an easy to use portal where a help desk tech (of varying skills) could run one of several scripts to create users or create Exchange mailboxes, without having direct access to those servers. Perhaps there is a better way to do this, but I didn't want them remoting into Exchange to run scripts or to install Exchange management tools on my Domain controllers. 

My PSWA server is running Server 2012 R2

We have two Domain controllers both running Server 2008 R2

I've checked both DCs, they both have ADWS enabled and running. I restarted the services on both and both run.

• Edited by ethanthekiwi Monday, August 17, 2015 9:07 PM

This problems has nothing to do with PowerShell Web Access (PSWA), and everything to do with the "second-hop" problem. You're connecting to a member server, and asking it to reach out to a Domain Controller on your behalf. That credential delegation is not permitted by default. The best way to fix this problem is to create a new endpoint that runs under a different account. That way when you ask the member server to talk to AD, that it does it, not with your account, but with the account that's running the endpoint.

Go to your member server and (1, below) check our the current endpoints. Create a new file that will assist you in creating a new endpoint, and that will import the AD module (2). When that's complete, register the new endpoint (3). Edit the permissions in the permission box that opens. The group you want to be able to use this endpoint will need read and execute. This is how we get around the only-admins-can-use-endpoints-by-default dilemma.

1. Run Get-PSSessionConfiguration.

2. Run New-PSSessionConfigurationFile -Path <give it a path and name>.pssc -ModulesToImport ActiveDirectory

3. Register-PSSessionConfiguration -Name <name your endpoint> -Path <path to pssc file above> - RunAsCredential domain\user -ShowSecurityDescriptorUI

4. Allow PowerShell to restart the necessary services.

Now, when someone connects via PowerShell, for an interactive session, they would do this: Enter-PSSession -Computer <member server> -ConfigurationName <the name you choose in step 3>. In PSWA, you click "Optional connection settings," and change the Configuration name there. Have fun and read lots!

Edit: Corrected spacing.

• Edited by tommymaynard Monday, August 17, 2015 9:53 PM

Thanks for the reply. 

I created that configuration on my shell server using a new user I created and granted permissions to my DCs. When I try to use the configuration file from the PSWA login page, it tells me 

An unexpected error occurred during the sign-in process. Try signing in again, or contact your system administrator.

When I login to PSWA without this and try to connect to that endpoint and configuration file it goes down like this:

PS C:\Users\ethanthekiwi\Documents> 

Register-PSSessionConfiguration -Name ad.powershell -Path "C:\Users\Public\Documents\remoting.pssc"

WARNING: Register-PSSessionConfiguration restarts the WinRM service and all dependent services.  

All WinRM sessions connected to Windows PowerShell session configurations, such as Microsoft.PowerShell and session con

figurations that are created with the Register-PSSessionConfiguration cmdlet, are disconnected.

Confirm

Are you sure you want to perform this action?

Performing the operation "Register-PSSessionConfiguration" on target "Name: ad.powershell SDDL: O:NSG:BAD:P(A;;GA;;;BA)

(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This lets selected users remotely run Windows PowerShell commands on t

his computer.".

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is 'Y'): y

PS C:\Users\ethanthekiwi\Documents> 

get-aduser -filter test.sam

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.

    + CategoryInfo          : ResourceUnavailable: (:) [Get-ADUser], ADServerDownException 

    + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADUser 

I ran all of the commands you listed on the shell server, not the DC. Do I need to run anything over on the DC to make it accept commands from here?

First off, I had a hard time following your post, but I'll try my best to continue to help.

I assume that when you say "shell server," that you're referring to a member server that has the RSAT installed, which will be reaching out to a Domain Controller for you, via an endpoint that's running as a different user. When you connect remotely, whether from PSWA or PowerShell, you'll be connecting to your endpoint on the member server.

On that server (not the PSWA server), is where you need to create the .pssc file and where you need to register the new endpoint. It's that server, that you'll be connecting to in order to run your Get-ADUser cmdlet. I didn't say it in my first post, but working with PSWA is practically the last step. It looks like you're trying to create endpoints inside PSWA -- don't do that. Again, do that on your member server, inside a PowerShell console.

The step right before the last step (using PSWA) is creating authorization rules on the PSWA server. Do this in PowerShell on the PSWA server, just like you did above. You'll need to create authorization rules to allow a user (or groups of users) the ability to connect to computer (or groups of computers). Without authorization rules, PSWA does not work. Use Get-PswaAuthorizationRule to view your rules, of which you'll likely not have any yet, and Add-PswaAuthorizationRule to create them. Read their help files if you have questions.

You don't need to run any commands on the DC. This still may not solve all your problems, but hopefully it keeps you pointed in the right direction. It can be an involved process, and it requires that you fully understand all the little pieces. Again, PSWA is practically the last step. Also, be sure that when you do get to your PSWA server and you get errors, that you read thought the eventlog. Microsoft has done a fairly good job on recording helpful information. Check in Event Viewer > Application and Services Logs > Microsoft > Windows > PowerShellWebAccess.