Cannot connect to Exchange Server console or shell from local machine
Hi, I recently installed exchange 2010. Upon launching either Exchange Management Console and clicking on "Microsoft Exchange On-Premises", I receive the following error: [server.domain.com] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true -CurrentVersion 'Version 14.1 (Build 218.15)". However, in EMC, when I manually add an exchange forest by specifying the URL http://server/PowerShell, I have no problems connecting to exchange. It seems as if the "Discover" command that is launched by "Microsoft Exchange On-Premises" is not working on this machine. Also, running Exchange Management Shell results in a similar error as above. Any troubleshooting tips or suggestions? thanks! -sul.
February 23rd, 2011 1:11pm

Have you went through the Possible causes above to insure none of them are the culprit? Check event viewer application log for more detailed information. Have you also verified DNS settings on Server?MVP Exchange Server
Free Windows Admin Tool Kit Click here and download it now
February 23rd, 2011 5:37pm

There is actually a good blog post written by the Exchange Server Product Group on the topic. Read it here: Troubleshooting Exchange 2010 Management Tools startup issuesJesper Bernle | Blog: http://xchangeserver.wordpress.com
February 24th, 2011 3:43am

There is actually a good blog post written by the Exchange Server Product Group on the topic. Read it here: Troubleshooting Exchange 2010 Management Tools startup issues Jesper Bernle | Blog: http://xchangeserver.wordpress.com Jesper, thank you for the reference. After going through the blog, I noticed that unfortunately, none of the issues listed on the blog resemble the above error. Regardless, I went through all of them and their possible causes and could not find anything wrong with my server settings. If you happen to have any additional information or suggestions that might be specific to the above error, please share, thanks again! -sul.
Free Windows Admin Tool Kit Click here and download it now
February 24th, 2011 8:17am

Have you went through the Possible causes above to insure none of them are the culprit? Check event viewer application log for more detailed information. Have you also verified DNS settings on Server? MVP Exchange Server John, thanks for the tip. If you happen to have information on exactly HOW to troubleshoot EACH of the possible causes, please share. I'm a bit of a newbie. I did however check the event logs and could not find any errors or warnings inside either the Application or System logs. Also, the DNS settings on this server seem correct, but if there is something specific I need to check, please feel free to advise. Thanks again! -sul.
February 24th, 2011 8:33am

Ok, in reference to your post "However, in EMC, when I manually add an exchange forest by specifying the URL http://server/PowerShell, I have no problems connecting to exchange" can you then run ExBPA in the EMC to see if finds any issues?MVP Exchange Server
Free Windows Admin Tool Kit Click here and download it now
February 24th, 2011 8:10pm

When you add a new Exchange Forest to the EMC, instead of specifying a URL try the FQDN of one of your CAS servers. The difference is that when specifying an URL you authenticate with Basic Authentication, while connecting with FQDN uses Kerberos.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
February 25th, 2011 12:45am

When you add a new Exchange Forest to the EMC, instead of specifying a URL try the FQDN of one of your CAS servers. The difference is that when specifying an URL you authenticate with Basic Authentication, while connecting with FQDN uses Kerberos. Another thing I thought of is if you perhaps have configured /owa redirection on the IIS. Have you? Jesper Bernle | Blog: http://xchangeserver.wordpress.com
Free Windows Admin Tool Kit Click here and download it now
February 25th, 2011 12:45am

Ok, in reference to your post "However, in EMC, when I manually add an exchange forest by specifying the URL http://server/PowerShell, I have no problems connecting to exchange" can you then run ExBPA in the EMC to see if finds any issues? MVP Exchange Server Hi John, I cannot run ExBPA from EMC because only the following tools are available: Role Based Access Control (RBAC) User Editor Message Tracking Call Statistics User Call Logs This is because I cannot connect via "Microsoft Exchange On-Premises. However, I ran ExBPA from command line. After runnig ExBPA, I only see error messages related to self-signed certificates as I have not purchased a third-party certificate as yet. If you like, I can export the report and post it. any suggestions? -sul.
February 25th, 2011 9:16am

When you add a new Exchange Forest to the EMC, instead of specifying a URL try the FQDN of one of your CAS servers. The difference is that when specifying an URL you authenticate with Basic Authentication, while connecting with FQDN uses Kerberos. Another thing I thought of is if you perhaps have configured /owa redirection on the IIS. Have you? Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, Perhaps I forgot to mention that my issue that I really need to connect via "Microsfot Exchange On-Premises". When I click on "Microsoft Exchange On-Premises, I get the the above error (in my first post). I have successfully connected by adding an Exchange Forest by specifying the FQDN, but I need "Microsoft Exchange On-Premises" to work. I also cannot connect via Exchange PowerShell using the following command: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'D:\Program Files\Microsoft Exchange\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto" The above command results in the same error message. Any suggestions? thanks! -sul.
Free Windows Admin Tool Kit Click here and download it now
February 25th, 2011 10:17am

You can change the way EMC connects to the Exchange Organization on the On-Premises node by selecting its Properties if you want to. How about the question regaring /owa redirection (or any other fiddeling about in IIS7 after setup)? I know your specific error message isn't stated to be found by the EMTshooter tool but had it been me I'd give it a try. Have a read (and download) about the tool here: Resolving WinRM errors and Exchange 2010 Management tools startup failures Jesper Bernle | Blog: http://xchangeserver.wordpress.com
February 25th, 2011 1:30pm

You can change the way EMC connects to the Exchange Organization on the On-Premises node by selecting its Properties if you want to. How about the question regaring /owa redirection (or any other fiddeling about in IIS7 after setup)? I know your specific error message isn't stated to be found by the EMTshooter tool but had it been me I'd give it a try. Have a read (and download) about the tool here: Resolving WinRM errors and Exchange 2010 Management tools startup failures Jesper Bernle | Blog: http://xchangeserver.wordpress.com Jesper, thank you again for the tips. From where can I select the "Properties" for Microsoft Exchange On-Premises? In my case, when I right-click on the Microsoft Exchange On-Premises object, the only menu items available to choose from are View, Refresh, and Help. There is no selection for Properties. Is there some other place I need to look at that I am not aware of? I have gone through the EMTshooter a couple of times I closely studied every "possible cause" listed on the blog and I did not find any inconsistencies. If you would like me to post the results of the script, please let me know and I'll be happy to share the results. Also, there is no redirection being done on IIS. I really appreciate all your help so far and look forward to any suggestions you have toward a possible fix, thanks again, -sul.
Free Windows Admin Tool Kit Click here and download it now
February 25th, 2011 1:44pm

It´s a bit strange you don't have the same options that I have. I'm using my Domain Administrator account so perhaps it's a permission thing?! However, please test one more thing; delete (or just rename) the file Exchange Managment Console found here: C:\Users\[User Profile]\AppData\Roaming\Microsoft\MMC\ and restart EMC.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
February 26th, 2011 12:52am

It´s a bit strange you don't have the same options that I have. I'm using my Domain Administrator account so perhaps it's a permission thing?! However, please test one more thing; delete (or just rename) the file Exchange Managment Console found here: C:\Users\[User Profile]\AppData\Roaming\Microsoft\MMC\ and restart EMC. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Jesper, thanks again for your reply! I am logged on as the Domain Administrator as well. I did what you suggested about deleting the Exchange Management Console file, and unfortunately, it did not resolve. I still cannot see "properties" as a choice on the Microsoft Exchange On-Premises object. Please let me know if you come across any other suggestions. Many thanks! -sul.
Free Windows Admin Tool Kit Click here and download it now
February 26th, 2011 12:20pm

By chance I happened to read about some of the common errors when connecting to Remote Powershell in a book this morning and one possible bad guy in this drama could be a faulty/incomplete upgrade from let's say RTM to SP1. So my next suggestion is to reapply Exchange 2010 SP1.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
February 27th, 2011 1:01am

By chance I happened to read about some of the common errors when connecting to Remote Powershell in a book this morning and one possible bad guy in this drama could be a faulty/incomplete upgrade from let's say RTM to SP1. So my next suggestion is to reapply Exchange 2010 SP1. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, what is the process of reapplying SP1? I tried to run the service pack and the following error was generated: "Some controls aren't valid. -Please select at least one server role to install." Under the server role selections, none of the check boxes are selectable. (i.e: Mailbox, Client, Hub, UM and Management Tools check boxes are checked but they are greyed out). Does this mean that I need to uninstall the installed roles first before reapplying SP1? If so which one should I remove first? Any suggestions? thanks! -s.
Free Windows Admin Tool Kit Click here and download it now
February 27th, 2011 9:29am

What happens if you on your Exchange Server, in EMS, run Discover-ExchangeServer and then fill in the account information from the account you used when installing Exchange 2010?Jesper Bernle | Blog: http://xchangeserver.wordpress.com
February 28th, 2011 10:15am

What happens if you on your Exchange Server, in EMS, run Discover-ExchangeServer and then fill in the account information from the account you used when installing Exchange 2010? Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, When I initially launch EMS, I obviously get the original error above followed by the message below: Failed to connect to an Exchange server in the current site. Enter the server FQDN where you want to connect.: When I enter JUST the server name. e.g.: SERVER, I get a message that says Connected to <SERVER>. and I can successfully administer Exchange with no problems. At this point, when I run Discover-ExchangeServer, a logon window pops up and I enter the credentials, i.e.: DOMAIN\Administrator and it's password. When I do this, I continue to be connected with Exchange with no problems. HOWEVER, when I enter the FQDN (e.g.: server.domain.com), I get the original error message again and it quits connecting to exchange. At that point, when I run Discover-ExchangeServer, it prompts me for the credentials and I enter the same credentials as above. It responds back with the FQDN but it does not connect successfully to the exhange server, i.e.: it never responds with "Connected to <SERVER>. and it does not recognize any exchange related commands. Please let me know if there is anything else I can try, Many thanks!! -sul.
Free Windows Admin Tool Kit Click here and download it now
February 28th, 2011 1:06pm

Could it be name resolution problems? Could you please verify that the FQDN of your Exchange Server resolves to the expected internal IP.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
March 1st, 2011 1:29am

Could it be name resolution problems? Could you please verify that the FQDN of your Exchange Server resolves to the expected internal IP. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, thanks for the suggestion. I pinged the FQDN from the Exchange Server and it correctly resolved with the correct internal IP address of the machine. Please let me know if there is anything else I should try, thanks! -sul.
Free Windows Admin Tool Kit Click here and download it now
March 1st, 2011 7:03am

This is what Microsoft says about this error message: Server Name Provided Doesn't Exist You can receive the following error message if the server name you specified in the remote Shell URL doesn't exist. To resolve this issue, verify the server name. For more information, see Connect Remote Exchange Management Shell to an Exchange Server. Copy Code [exchserver01] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or us e HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc eption + FullyQualifiedErrorId : PSSessionOpenFailed Taken from here: Troubleshooting the Exchange Management Shell Jesper Bernle | Blog: http://xchangeserver.wordpress.com
March 2nd, 2011 2:15am

This is what Microsoft says about this error message: Server Name Provided Doesn't Exist You can receive the following error message if the server name you specified in the remote Shell URL doesn't exist. To resolve this issue, verify the server name. For more information, see Connect Remote Exchange Management Shell to an Exchange Server. Copy Code [exchserver01] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or us e HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc eption + FullyQualifiedErrorId : PSSessionOpenFailed Taken from here: Troubleshooting the Exchange Management Shell Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, thank you for the link to the Microsoft page. I have read through it entirely and unfortunately I was unable to determine how this relates to the fqdn issue in question. The text keeps mentioning connections to a remote exchange server via FQDN, but in my case, I'm simply unable to connect to Exchange using FQDN. I have no problems connecting to EMC or EMS when I specify just the server name by itself. For example, I cannot successfully connect to exchange on the local exchange server when I type: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://server.domain.com/PowerShell/ -Authentication Kerberos but when I type the following it works fine: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://server/PowerShell/ -Authentication Kerberos Is there perhaps a step-by-step way to troubleshoot why EMC or EMS does not like FQDN but has not problem with just the server name? Thanks! -s.
Free Windows Admin Tool Kit Click here and download it now
March 2nd, 2011 6:55am

Well, there is Test-PowerShellConnectivity in EMS, so try that cmdled out.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
March 4th, 2011 12:35am

Well, there is Test-PowerShellConnectivity in EMS, so try that cmdled out. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, the following were the results from running the script: WARNING: The test couldn't test the internal URL of this virtual directory, because the InternalURL property isn't set. CasServer LocalSite Scenario Result Latency(MS) Error --------- --------- -------- ------ ----------- ----- MESSAGE Default-Fi... Logon Skipped The test couldn't tes... WARNING: No Client Access servers were tested. I am not certain which virtual directory it is referring to. Is it the internalURL of Autodiscover, ecp, EWS, Activesync, OAB, owa or some other place? Any suggestions? thanks! -sul.
Free Windows Admin Tool Kit Click here and download it now
March 4th, 2011 2:17pm

I'd guess it's the AutoDiscoverServiceInternalUri that´s not set. In EMS issue the command Get-ClientAccessServer | ft Name, *internal* to check if you spot any error in the configuration. It should say something like https://CASserverfqdn.yourdomain.com/autodiscover/autodiscover.xml. If not issue Set-ClientAccessServer -Identity "CAS-01" -AutoDiscoverServiceInternalUri "https://cas01.contoso.com/autodiscover/autodiscover.xml" -AutoDiscoverSiteScope "Mail" Set-ClientAccessServerJesper Bernle | Blog: http://xchangeserver.wordpress.com
March 5th, 2011 12:05am

the whole story fully like mine! but mine is worse.. 1 - i don't have Test-PowerShellConnectivity Get-ClientAccessServer | ft Name, *internal* PS write "is not recognized as the name of a cmdlet, function, script file..." about them 2 - and in the IIS in basic setting while i press test setting on "autodiscover", "powershell" and "owa" virtual directories i got an error "invalid application path" .. while OWA, for example, works good through the IE web browser.. windows server 2008 R2 SP1 + exchange 2010 SP1 + rollup2 if it will helps.. where is theese cmdlets are located ? are they exe or dll files ? can i somehow add them ? what the hell is going on with virtual directories in IIS ? i will be appritiate any help, 3 day of war with it did not make a big victory for me.. Thank you!
Free Windows Admin Tool Kit Click here and download it now
March 5th, 2011 1:01am

the whole story fully like my! but my is worse.. 1 - i don't have Test-PowerShellConnectivity Get-ClientAccessServer | ft Name, *internal* PS write "is not recognized as the name of a cmdlet, function, script file..." about them 2 - and in the IIS in basic setting while i press test setting on autodiscover, powershell and owa virtual directories i got an error "invalid application path" .. while OWA works through the IE web browser.. windows server 2008 R2 SP1 + exchange 2010 SP1 + rollup2 if it will helps.. where is theese cmdlets are located ? are they exe or dll files ? can i somehow add them ? what the hell is going on with virtual directories in IIS ? i will be appritiate any help, 3 day of war with it did not make a big victory for me.. Thank you!
March 5th, 2011 1:01am

i don't have Test-PowerShellConnectivity Get-ClientAccessServer | ft Name, *internal* PS write "is not recognized as the name of a cmdlet, function, script file..." I assume you realize these are two separate commands, right? So, it's Get-ClientAccessServer or Test-PowerShellConnectivity. Do you run them locally on your Exchange Server? Do you have all the necessary permissions?Jesper Bernle | Blog: http://xchangeserver.wordpress.com
Free Windows Admin Tool Kit Click here and download it now
March 5th, 2011 3:18am

i've just start the BEFORE i connect to the exchange server )) [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Test-PowerShellConnectivity CasServer LocalSite Scenario Result Latency(MS) Error --------- --------- -------- ------ ----------- ----- EXCH-SRV Default-Fi... Logon User Success 412.04 [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-ClientAccessServer | ft Name, *internal* Name AutoDiscoverServiceInternalUri ---- ------------------------------ EXCH-SRV https://exch-srv.veditour.local/Autodiscover/Autodiscove... [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts> it's all ok ? but when i start console or shell i see VERBOSE: Connecting to EXCH-SRV.veditour.local [exch-srv.veditour.local] Connecting to remote server failed with the following error message : WinRM cannot process th e request. The following error occured while using Kerberos authentication: The network path was not found. i can change -auto in shell shortcut to FQDN and it will works correct! in console i can type exch-srv and it will work, but if i will write FQDN there will be the same error! what else .. IIS error.. i told them, am i ? no possibility to unisntall or reinstall EXCH or SP1.. because of unavailability of checkboxes on the roles other words in rest of the case my problem is fully like your.. differences i wrote upper... what the differences between FQDN and the short name ? and why is it so ?? P.S. Exchange was installed a month ago SP1 on windows 25.02 problems apperas 01.03 with console with our common error and this in log "The following fatal alert was generated: 10. The internal error state is 1203." source schannel, ID 36888 (so there are MANY errors in system log still) reboot helped next day problem appears once more.. reboot didn't helped. i installed SP1 on Exchange and rollup 2 on SP1.. and no better.. i have no ides.. maybe masters can help me ?
March 5th, 2011 4:00am

i've just start the BEFORE i connect to the exchange server )) [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Test-PowerShellConnectivity CasServer LocalSite Scenario Result Latency(MS) Error --------- --------- -------- ------ ----------- ----- EXCH-SRV Default-Fi... Logon User Success 412.04 [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-ClientAccessServer | ft Name, *internal* Name AutoDiscoverServiceInternalUri ---- ------------------------------ EXCH-SRV https://exch-srv.veditour.local/Autodiscover/Autodiscove... [PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts> it's all ok ? but when i start console or shell i see VERBOSE: Connecting to EXCH-SRV.veditour.local [exch-srv.veditour.local] Connecting to remote server failed with the following error message : WinRM cannot process th e request. The following error occured while using Kerberos authentication: The network path was not found. i can change -auto in shell shortcut to FQDN and it will works correct! in console i can type exch-srv and it will work, but if i will write FQDN there will be the same error! what else .. IIS error.. i told them, am i ? no possibility to unisntall or reinstall EXCH or SP1.. because of unavailability of checkboxes on the roles other words in rest of the case my problem is fully like your.. differences i wrote upper... what the differences between FQDN and the short name ? and why is it so ?? P.S. Exchange was installed a month ago SP1 on windows 25.02 problems apperas 01.03 with console with our common error and this in log "The following fatal alert was generated: 10. The internal error state is 1203." source schannel, ID 36888 (so there are MANY errors in system log still) reboot helped next day problem appears once more.. reboot didn't help. i installed SP1 on Exchange and rollup 2 on SP1.. and no better.. i have no ideas.. maybe masters can help me ?
Free Windows Admin Tool Kit Click here and download it now
March 5th, 2011 4:01am

I'd guess it's the AutoDiscoverServiceInternalUri that´s not set. In EMS issue the command Get-ClientAccessServer | ft Name, *internal* to check if you spot any error in the configuration. It should say something like https://CASserverfqdn.yourdomain.com/autodiscover/autodiscover.xml. If not issue Set-ClientAccessServer -Identity "CAS-01" -AutoDiscoverServiceInternalUri "https://cas01.contoso.com/autodiscover/autodiscover.xml" -AutoDiscoverSiteScope "Mail" Set-ClientAccessServer Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, thanks for the suggestion. I did not notice an error in the AutoDiscoverServiceInternalUri setting. It is correctly configured as https://<FQDN>/Autodiscover/Autodiscover.xml however, the AutoDiscoverSiteScope is configured as: {Default-First-Site-Name} Is this ok? Please let me know if you have any additional suggestions. Many thanks for your continued help! -sul.
March 5th, 2011 10:57am

however, the AutoDiscoverSiteScope is configured as: {Default-First-Site-Name} Is this ok? Default-First-Site-Name is the prepopulated Site name and if you haven't renamed your Site (which I think you have not) then all is in order.Jesper Bernle | Blog: http://xchangeserver.wordpress.com
Free Windows Admin Tool Kit Click here and download it now
March 6th, 2011 8:16am

however, the AutoDiscoverSiteScope is configured as: {Default-First-Site-Name} Is this ok? Default-First-Site-Name is the prepopulated Site name and if you haven't renamed your Site (which I think you have not) then all is in order. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, OK thanks! Since everything seems correctly configured and no changes were necessary, do you have any other suggestions? Many thanks! -sul.
March 6th, 2011 9:00am

however, the AutoDiscoverSiteScope is configured as: {Default-First-Site-Name} Is this ok? Default-First-Site-Name is the prepopulated Site name and if you haven't renamed your Site (which I think you have not) then all is in order. Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, OK thanks! Since everything seems correctly configured and no changes were necessary, do you have any other suggestions? Many thanks! -sul. Hi Jesper, just wondering whether you might have any other ideas or troubleshooting tips for this issue. If not, no worries. thanks for all your help, -sul.
Free Windows Admin Tool Kit Click here and download it now
March 9th, 2011 1:47pm

I´ve been thinking so long and hard that my brain is even more wrinkled than before ;-) If it happened to me I'd reinstall the CAS role to see if that fixes things. But I admit it's a rather drastic troubleshooting step ;-)Jesper Bernle | Blog: http://xchangeserver.wordpress.com
March 9th, 2011 11:38pm

I had the same problem after renaming my cas servers. Deleting and recreating my local profile on that Exchange server fixed it. I wasn't able to find the file or regkey that contained the old server name that caused this.
Free Windows Admin Tool Kit Click here and download it now
March 10th, 2011 10:05am

I had the same problem after renaming my cas servers. Deleting and recreating my local profile on that Exchange server fixed it. I wasn't able to find the file or regkey that contained the old server name that caused this. ®win, Thanks for the suggestion. I deleted and recreated the local profile and unfortunately, it had no affect on the problem. thanks! -sul.
March 10th, 2011 10:39am

I´ve been thinking so long and hard that my brain is even more wrinkled than before ;-) If it happened to me I'd reinstall the CAS role to see if that fixes things. But I admit it's a rather drastic troubleshooting step ;-) Jesper Bernle | Blog: http://xchangeserver.wordpress.com Hi Jesper, thanks again for all you help. I think I may be getting a little closer to the root cause of this issue, which seems to be related to WinRM. It seems that running any winrs command with FQDN only works when I explicitly supply the user credentials, for example: winrs -r:server.domain.com -username:DOMAIN\administrator -password:********* dir somehow, the command requires authenticating with credentials when the FQDN is being used but I don't know enough to troubleshoot what is causing this behavior. If I use the server name by itself, the username and password credentials are not required. I even added *.domain.com to TrustedHosts and it did not help. If I run the above command without the credentials, I get the original 'The network path was not found...' error message, which is what I get every time I try to run EMC or EMS. thanks! -sul.
Free Windows Admin Tool Kit Click here and download it now
March 10th, 2011 10:57am

I think it might be better to continue this troubleshooting in your other post here: http://social.technet.microsoft.com/Forums/en-US/winserverpowershell/thread/78054d35-d3fc-4872-ba46-f1c1c59383b5Jesper Bernle | Blog: http://xchangeserver.wordpress.com
March 11th, 2011 12:20am

Install the WinRm IIS extensions and run winrm quickconfig
Free Windows Admin Tool Kit Click here and download it now
April 3rd, 2011 6:03pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics