Exchange 2010 console error

I've introduced a new Windows 2008 R2 DC into a network having one 2003 DC w/Exchange 2003 installed on it. Everything was fine for a while but after a few reboots I can no longer use the Exchange 2010 management console.

I get:  WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.

My intent was to migrate everyone to the new server and remove the old one. I've migrated all the FSMO roles and mailboxes but the old server is still in the picture as a DC.
netman09Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

netman09Author Commented:
Also, I've already been through checking powershell in IIS. It may be note worthy that IUSR_NEWSERVER name doesn't exist. Just the IUSR_OLDSERVER name, but like I said, everything was working. Maybe an update applied during a reboot or something that made it stop working?
netman09Author Commented:
The result of the winrm get winrm/config/winrs is

    AllowRemoteShellAccess = true
    IdleTimeout = 180000
    MaxConcurrentUsers = 5
    MaxShellRunTime = 2147483647
    MaxProcessesPerShell = 15
    MaxMemoryPerShellMB = 150
    MaxShellsPerUser = 5

I can't find any problems, I'm missing something simple I just know it.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

netman09Author Commented:
In my original post I forgot to mention that the new server is where I installed the Exchange 2010 Enterprise server software and migrated the mailboxes to. The Exchange Shell asks for FQDN of the server and after typing it in doesn't connect.
BusbarSolutions ArchitectCommented:
shave you tried to create a new management console from MMC and Exchange snap int to it and try again
netman09Author Commented:
Yes, but like I said, even the shell can't find the path. Outlook clients are working and the owa works fine. The system is sending and receiving emails but I can't manage the system. I'm sure this has to do with IIS in some way but I'm not seeing the problem. SO CONFUSED.
BusbarSolutions ArchitectCommented:
can you  try to re-install winrm and re-install the administrative tool using the setup
netman09Author Commented:
I'm not sure how to reinstall winrm. I've tried and I'm obviously not doing it right. I've tried finding it under features to no avail and also using winrm to delete the listener but I'm not doing that right cause it doesn't like the way I'm typing the address+transport.
Shreedhar EtteCommented:
Hi,

Does you have AVG installed on the server? If yes, then disbale it and try to open the Conolse.

Hope this works,
Shree
BusbarSolutions ArchitectCommented:
if the Exchange server is 2008 sp1 or sp2 then here is a link:
http://www.microsoft.com/downloads/details.aspx?FamilyId=d37e25cf-db05-4b23-a852-cdf865d81b82
or:
Server Manager -> Features -> Add Features -> Scroll down to the bottom -> Check off Windows PowerShell Integrated Scripting Enviornment (ISE) -> Install
netman09Author Commented:
I can get into the management shell and the management console by not using the FQDN but instead specifying the hostname of the server only. Does this help? Here is the winrm config.

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5
netman09Author Commented:
I've opened a Microsoft incident but won't here back from them for awhile. Being able to open the console helps though. Instead of listening for authentication at hostname.domain.com, it's listening only on the hostname. How do I fix this?
netman09Author Commented:
This article has the exact error I'm seeing but I can't figure out how to fix it.

http://technet.microsoft.com/en-us/library/dd351136.aspx
Under "Connection Issues" - "Server Name Provided Doesn't Exist"
 
Shreedhar EtteCommented:
netman09Author Commented:
Yea, I'm sure it's not a problem authenticating but addressing the server. Like I said, if instead of the FQDN (hostname.domain.com) I enter just the hostname it logs in just fine. It's like the FQDN is not associated with the WinRM config.
netman09Author Commented:
Turns out that the problem was in c:\Users\Administrator.domainname\AppData\Roaming\Microsoft\Exchange\RemotePowerShell. I deleted the folder and vwahlah! I found this out when I created a new user with the same rights as Administrator and logged in. It worked fine so I figured the profile had issues.

Also, the Microsoft engineer said stay away from rollup 3 as this has been a problem with others after installing the rollup. He recommended rollup 2 instead.

Thanks for your time and energy though.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
eportproitCommented:
i tried this solution, but didn't work
JerDawgCommented:
Had the same issue with Exchange 2010 on SBS 2011.  Confirmed it was profile dependent by creating another admin profile -- it runs fine in alt admin profile.  However, in SBS 2011, this path cannot be located (to try reset):c:\Users\Administrator.domainname\AppData\Roaming\Microsoft\Exchange\RemotePowerShell
Searched for it to no avail.  Good news is that I can manage Exchange using the EMC in the alt. admin profile until it is figured out.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.