locked
EMC and Shell issue - Access is Denied RRS feed

  • Question

  • Access is denied. It was running command ‘Discover-ExchangeServer -UseWIA $true’

     

    Just installed Exchange 2010 on Windows 2008 Standard server. I have come across this now after spending hours researching. It is a clean install with one 2007 Exchange server running. I have seen several forums stating permission issues and how you need to enable powershell, which all has been done. I'm thinking maybe an issue with IIS or active directory. Any advise?

    Monday, April 19, 2010 3:31 AM

Answers

  • To close this one out, the issue was that OCS was previously installed on the machine. We had to remove the AD entrys manually as the machine name was still the same. Microsoft updated the know issues section. Thanks.
    • Marked as answer by onlinecsr Thursday, December 30, 2010 2:21 AM
    Thursday, December 30, 2010 2:21 AM

All replies

  • Hi,

    Kindly go through the following thread which provide information on similar issue.

    http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/fbdb590c-d6aa-43eb-9198-9c96123ce32f

     


    With Best Regards Anbu
    Wednesday, April 21, 2010 1:24 PM
  • Try this,

    Disable anonymous authentication for powershell on IIS

    set-user -identity contoso.com\administrator -remotepowershellenabled: $true


    Clement Rosario
    Wednesday, April 21, 2010 1:39 PM
  • Hi,

    Any update on this issue?


    With Best Regards Anbu
    Friday, April 23, 2010 6:24 PM
  • Ok, got some good news, but I am not sure where this leaves us. I tried David's fix "EMC Permissions Gone Part Deux", but it did not change anything. Like I said, this is a new exchange install and I have formated the system and reinstalled the OS three times. Same common factor, the computer name and hardware. I am thinking it is something in AD. I just tried changing the computer name to see if it would have any change, which it allowed me access to the console. What in AD is tied to this computer name on the exchange server side? I need to stick to our naming scheme. I am positive the root of the issue is in the AD now. I will state below again what we have here.

     

    New server hardware - Server 2008 Standard 64 fresh install with Exchange 2010 fresh install

    Existing Exchange 2007 server (64 bit) on Server 2008 Standard 64- different server, existing AD

    Sunday, April 25, 2010 4:07 AM
  • Just to add, output from before is below.

    Connecting to New Exchange Forest.
    The attempt to connect using HTTPS protocol "Kerberos" failed: Connecting to remote server failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
    The attempt to connect using HTTPS protocol "Basic" failed: Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Unencrypted traffic is currently disabled in the client configuration. Change the client configuration and try the request again. For more information, see the about_Remote_Troubleshooting Help topic.

    Tried to connect giving auth to EMC. Will only give Access is denied at command line.

    Sunday, April 25, 2010 4:12 AM
  • Hello.

    Please reproduce the problem and let us know first 5 events in Security event log.

    Per my latest experience this problem happens due to time different between exchange server and Domain controller. So please check whether your time, date, time zone and AM/PM are the same on both servers.

    Regards  

     

     


    Chinthaka Shameera | MCITP: EA | MCSE: M | http://howtoexchange.wordpress.com/
    Sunday, April 25, 2010 5:30 AM
  • I just checked time on DC and the new Exchange server. There is no time difference. I too have looked into the security logs. It shows the following when trying to log on.

    A logon was attempted using explicit credentials.

    Subject:
     Security ID:  SYSTEM
     Account Name:  110K6M1$
     Account Domain:  CSRTECHNOLOGYGR
     Logon ID:  0x3e7
     Logon GUID:  {00000000-0000-0000-0000-000000000000}

    Account Whose Credentials Were Used:
     Account Name:  SYSTEM
     Account Domain:  NT AUTHORITY
     Logon GUID:  {00000000-0000-0000-0000-000000000000}

    Target Server:
     Target Server Name: localhost
     Additional Information: localhost

    Process Information:
     Process ID:  0x1094
     Process Name:  C:\Windows\System32\svchost.exe

    Network Information:
     Network Address: -
     Port:   -

    This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials.  This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command. 

    An account was successfully logged on.

    Subject:
     Security ID:  SYSTEM
     Account Name:  110K6M1$
     Account Domain:  CSRTECHNOLOGYGR
     Logon ID:  0x3e7

    Logon Type:   5

    New Logon:
     Security ID:  SYSTEM
     Account Name:  SYSTEM
     Account Domain:  NT AUTHORITY
     Logon ID:  0x3e7
     Logon GUID:  {00000000-0000-0000-0000-000000000000}

    Process Information:
     Process ID:  0x1094
     Process Name:  C:\Windows\System32\svchost.exe

    Network Information:
     Workstation Name: 
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Advapi 
     Authentication Package: Negotiate
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon session is created. It is generated on the computer that was accessed.

    The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

    The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

    The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    Special privileges assigned to new logon.

    Subject:
     Security ID:  SYSTEM
     Account Name:  SYSTEM
     Account Domain:  NT AUTHORITY
     Logon ID:  0x3e7

    Privileges:  SeAssignPrimaryTokenPrivilege
       SeTcbPrivilege
       SeBackupPrivilege
       SeRestorePrivilege
       SeDebugPrivilege
       SeAuditPrivilege
       SeImpersonatePrivilege

    An account failed to log on.

    Subject:
     Security ID:  NULL SID
     Account Name:  -
     Account Domain:  -
     Logon ID:  0x0

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  
     Account Domain:  

    Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xc000006d
     Sub Status:  0xc000006a

    Process Information:
     Caller Process ID: 0x0
     Caller Process Name: -

    Network Information:
     Workstation Name: -
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Kerberos
     Authentication Package: Kerberos
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    An account failed to log on.

    Subject:
     Security ID:  NULL SID
     Account Name:  -
     Account Domain:  -
     Logon ID:  0x0

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  
     Account Domain:  

    Failure Information:
     Failure Reason:  Unknown user name or bad password.
     Status:   0xc000006d
     Sub Status:  0xc000006a

    Process Information:
     Caller Process ID: 0x0
     Caller Process Name: -

    Network Information:
     Workstation Name: -
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Kerberos
     Authentication Package: Kerberos
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    The last two out of five fail everytime. It shows "Unknown user name or bad password." but this is the same account that it was installed with.

    Sunday, April 25, 2010 3:26 PM
  • Ok update, just uninstalled the exchange server and restarted, renamed windows 2008 server and reinstalled exchange server. It came up into EMC with no problem right after install. What appers to be the issue here? I have to say I think it is active directory. What is the fix?
    Sunday, April 25, 2010 4:05 PM
  • This might help, using ADSIEDIT make sure that SPN HTTP/<servername> is on the machine account of your server

    (<servername> is your server's FQDN) I found that SPN was on the SIP service account running OCS on the server, moved it to the machine account for the server rebooted and Exchange 2010 management console now works and remote management and OCS still works as well (as far as I can tell) using the modified SIP service account.

    use the script below to locate HTTP/*  SPN to find where they are registered.

    Script for SPN query http://technet.microsoft.com/en-au/library/ee176972.aspx

    Thursday, May 27, 2010 5:25 AM
  • To close this one out, the issue was that OCS was previously installed on the machine. We had to remove the AD entrys manually as the machine name was still the same. Microsoft updated the know issues section. Thanks.
    • Marked as answer by onlinecsr Thursday, December 30, 2010 2:21 AM
    Thursday, December 30, 2010 2:21 AM