Friday, May 31, 2013

Problem with WinRM on Exchange 2013 Management Shell and Exchange Toolbox on a new exchange 2013 with CAFE and BE on single server installation

While deploying MS Exchange 2013 I experienced issues with accessing the Exchange Management Shell and Exchange Toolbox. Whenever I tried to open the Exchange Management Shell I kept get the following error:


VERBOSE: Connecting to Exchange2013.DOMAIN.LOCAL
New-PSSession : [exchange2013.domain.local] Connecting to remote server exchange2013.domain.local failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.domain.local) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


VERBOSE: Connecting to EXCHANGE2013.LOCAL.COM.
New-PSSession : [exchange2013.domain.local:80] Connecting to remote server exchange-bt.tmal.com failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (exchange2013.local.COM:80) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubleshooting Help topic.


Workaround and Resolution:

Searching the error on Google and all over the web resulted in various and numerous solutions most that worked for there environment but failed to address my issue, but made me realize that this was a Powershell website issue.
Exchange 2013 installs a Default Website (Client Access front End) on port 80 and 443 and also a Backend Website on port 81 and 444.

Here is how i managed to sort out my issue, I had to Change the physical path from: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell to: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell and then issued an IISRESET.

This is how I went about diagnosing this, with the first Exchange Server 2013 installed and running, I installed a second Exchange 2013 Server with only the Mailbox server role.
On the second Exchange Mailbox server I was able to access the EMS and the Exchange Toolbox successfully.
Now from here on it's simple I only have to do a comparison of the Powershell settings in IIS Manager on these two Exchange servers.

Internet Information Services (IIS) Manager, Sites, Default Web Site, PowerShell and in the Actions Pane, choose Basic setting, physical Paths - on exchSvr1 has C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell while exchSvr2 has C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell on exchSvr1 changed the physical path to C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell

After changing all these i did an iisrest on the exchSvr1 (the affected server) and tried the EMS and Exchange Toolbox, they all worked.

Wednesday, February 24, 2010

Gateway Load Balancing and Router Redundancy with HSRP & GBLP

I have two ISP's providing VPN links between my HQ and three remote offices, we are using broadband links and Leased Lines in all the sites, the idea for this is to provide route redundancy/failover in case one router fails.

I did some research on how best to achieve this, and two Cisco technologies were highly recommended for this; Gateway Load Balancing Protocol (GLBP) and Hot Standby Router Protocol (HSRP).

GLBP is cisco's newest Gateway redundancy feature and it operates @ layer 2. It elects one of the members of the GLBP Virtual Gateway, and this acts as the ARP responder.

HSRP is a cisco proprietary redundancy protocol for establishing a fault-tolerant default Gateway. The protocol establishes a framework between network routers in order to achieve default gateway failover. If the primary gateway should become inaccessible, in close association with a rapid-converging routing protocol like BGP, EIGRP or OSPF.

more reading : Redundant Protocols - GBLP, HSRP , HSRP vs BGLP vs VRRP , How to Configure HRSP for Load Balancing

Of the two protocols, I had to settle for HSRP as I only have a few client computers in remote sites that one link could easily handle so load balance is not necessary.

Sample Config for Site A

Router A

int FastEthernet0/0
ip address 1.0.0.1 255.0.0.0
standby 1 preempt
standby 1 ip 1.0.0.3
standby 1 priority 110

Router B

int FastEthernet0/1
ip address 1.0.0.2
standby 1 preempt
standby 1 ip 1.0.0.3



Router B - f0 = 7

Thursday, September 17, 2009

Cacti not producing graphs or creating rrd

yesterday i was installing cacti on my debian 4.0 box, which i normally use for monitoring my network, after the installation and configurations, i realised that cacti was not plotting the graphs for the devices I had added, even status was showing Unknown on all devices.

I checked both snmp and rrdtool, but both were running smoothly, this was a bit strange as even the /usr/share/cacti/site/rra folder was blank, cat /var/log/apache2/error.log resulted in:

localhost_server_traffic_in_18.rrd': No such file or directory ERROR: opening '/usr/share/cacti/site/rra
etc etc.
running the php poller file manually from the shell came back with: Fatal error: Call to undefined function: mysql_pconnect() in /usr/share/php/adodb/drivers/adodb-mysql.inc.php on line 377.

This was really interesting as i am having phpmyadmin running smmothly without problems, so why does my php seem to break in cacti, on the cacti forum somebody pointed that cacti package depends on php5-cli, i checked and realised i was having php4-cli on my box, apt-get install php5-cli sorted out this, and i have my graphs in Cacti

Monday, August 10, 2009

Error message when you try to log on to a Windows Server 2000 - based terminal server

Last week, I installed and run spybot on a Windows 2000 terminal server, and also some windows updates (NB; For some reason or another, but not known to me, this server has never had any windows and antivirus updates for some time, and it was showing signs of infections), after a restart over the weekend due to the updates, Users this morning started reporting failure to log on to the terminal server with this error:

"Windows cannot log you because the profile cannot be loaded. Please contact your network Administrator (in this case me), insuficiet system resources exists to complete the requested service"

Now, I half expected this or atleast some problems to surface after the maintenance work I did on the server.

However, it did take me a good 30 minutes to sort this one out, microsoft knowledge base, suggested two things, first increasing the maximum registry value (Control Panel -> system -> advanced -> perfomance options -> Change

Secondly tweaking the registry.
  1. click start -> run -> type regedit and hit Enter.
  2. Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
  3. On the Edit menu, point to New and then click DWORD value
  4. In the New Value #1 box, type PoolUsageMaximum, and then pres ENTER.
  5. Right-click PoolUsageMaximum, and then click Modify
  6. In the value data box, type 60, click Decimal, and then click ok
  7. if the PagedPoolSize registry entry exists, go to step 8. If the PagePoolSize registry entry does not exist, create it. ( Edit Menu -> New -> DWORD Value -> type PagedPoolSize in the New Value #1 box, and press Enter.)
  8. Right-click PagedPoolSize, and thn click OK
  9. Exit Registry Editor, and then restart the computer.
Everybody, is working fine now and the phones have gone queit

Wednesday, August 05, 2009

Trouble Shooting WSUS problems - Clients not populating in WSUS Admin Console

I have had to install WSUS twice on my server due to conflicts with SEPM, the first install WSUS was configured to use Port 80, and I used the Default Domain Policy to direct Client Computers to it.

when i was reinstalling the WSUS to use port 8530, i created a policy called WSUS on the DC, that would control clients automatic Update configuration. unforunately only 4 out of over 120 PC's only reported to the WSUS.

Doing Start ->Run, then rsop.msc on one of the failing machines showed Group Policy was not being applied correctly, i realised that the Default domain Policy was still having the old settings of my first WSUS configuration i.e. the intranet update server was showing http://servename instead of http://servername:8530.

Cleaning out the Default Domain Policy of all windows Updates setting and allowing the WSUS policy that had the right settings did the trick, all my computers populated and reported to the WSUS Console within hours.

Setting Up a WSUS Server along with SEPM

Recently i installed WSUS on a server running Symantec endpoint protection Manager using default settings, and i didn't know that this is not recommended until my SEPM stopped working correctly..

The problem is both WSUS and SEPM create a virtual directory in IIS called content, and whichever was installed first will stop working, normally it's recommended to install WSUS on Port 8530 on a server where sharepoint or SEPM is already installed.

So basically I had to unistall the WSUS, sort out my SEPM, and re-installed my WSUS to use port 8530 and it's own virtual content directory and update the group policy to point to http://servername:8530.

After this I had WSUS and SEPM working in harmony.

Issues with Symantec Endpoint Protection Manager not updating Win32 Clients

For the last three weeks I have struggled to get my SEPM to update win32 clients, what was happening is, only the 64 bit machines running Windows 2008 server were the only machines getting updates from the management server, this was surprising indeed as the SEPM has been functioning without any problems until this point.

Trying to trouble shoot the problem, i started with the usual, reviewing the changes that have taken place between then (meaning when updates were running) and now. I had installed a WSUS server on the same server as my SEPM, so i tried unistalling the WSUS and followed step by step instructions from symantec on how to recover from this situation. all in all, this did not work, it was a desperate situation for me as all my Windows XP and Vista machine ere not updating so I had to allow manual updates.

Yesterday while I was on google, i found a post of almost the same issue with SEPM, so itried the solution and suddenly I had all my client PC's updating.

Briefly this is how i fixed this,
  • Log on to ftp://ftp.symantec.com/AVDEFS/symantec_antivirus_corp/jdb/ and download the latest definitions (NB: they will have .jdb extension).
  • copy the downloaded Defn to "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\data\inbox\content\Incoming" (this is on the SEPM server)
  • In a period of 30 seconds to a minute the .jdb will be processed and all files and subfolders will be processed
to verify that the SEPM has been updated, open "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\content\{C60DC234-65F9-4674-94AE-62158EFCA433}" you should see a folder or folders with the ymmddxxx naming convention, look for the current folder , inside it should have a folder named full and a zip file named full as well.

This cleared whatever was blocking my liveupdate, now it's working just fine.