 | | |
| | |
|
Spaces home  System Center Operations...PhotosProfileFriendsMore |  Tools   |
System Center Operations Manager 2007Bringing IT 24/7/365 to a Data Center Near You
|
|||||||||||||
|
|
July 23 Script: List all Performance Monitors & their ThresholdsCourtesy of Brain Wren: http://blogs.technet.com/brianwren/ OpsMgr 2007: The Operations Manager 32-bit agent is supported on 64-bit Operating Systemshttp://blogs.technet.com/smsandmom/archive/2008/07/22/opsmgr-2007-the-operations-manager-32-bit-agent-is-supported-on-64-bit-operating-systems.aspx | Comments I get asked this every once in a while and since I couldn't find it mentioned anywhere I thought it might be a good idea to post it here. Under certain circumstances it may be necessary to install the OpsMgr 32-bit agent on a 64-bit operating system to monitor a 32-bit application. This is a supported configuration but the 32-bit agent must be installed manually and both the 32-bit and 64-bit OpsMgr agent cannot be installed simultaneously. It may also be necessary to install the OpsMgr 32-b SQL Reporting Services error browsing localhost/reports "The XML page cannot be displayed"http://CameronFuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1416.entry | Comments SQL Reporting Services error browsing localhost/reports “The XML page cannot be displayed”
I ran into a new issue during a recent installation of System Center Operations Manager 2007 on Windows 2003 with SQL 2005 SP2. I’m not sure if it was the order of what prerequisites were applied, or some other spatial anomaly, but the end result was an inability to install the reporting components for Operations Manager 2007. As a background, checking to make sure that the two sql reporting services websites function is a really good idea before attempting to install the OpsMgr reporting components. Checking the likely issues I browsed to http://localhost/reportserver and http://localhost/reports on the server I was trying to install the OpsMgr components.
The reports website was failing with a new error: “The XML page cannot be displayed”.
After digging through search engines and trying a variety of different methods to resolve the problem, I found that the following fixed the website: · From the command prompt, moved into the c:\windows\microsoft.net\framework64\v2.0.50727 directory (this was occurruing on a Windows Server 2003 x64 platform so the framework was in the framework64 directory versus the framework directory for x86 systems) · Ran an aspnet_regiis –u (to remove the v2 version of asp.net) · Ran an aspnet_regiis –i (to re-add the v2 version of asp.net) · Ran an iisreset to reset the websites, and re-browsed to the http://localhost/reports and http://localhost/reportserver directories.
The reports virtual was now working correctly. I ended up also needing to use the Reporting Services Configuration tool to apply the default settings to the Report Server Virtual directory to get the http://localhost/reportserver virtual working. Within the Reporting Services Configuration tool check for any errors. It should be green for the Server Status, Report Server Virtual Directory, Report Manager Virtual Directory, Windows Service Identity, Web Service Identity, Database Setup, Initialization and Execution Account. It was blue for my SharePoint Integration and Encryption Keys, and yellow for my Email Settings.
Once this was done, the installation of the reporting components for Operations Manager 2007 installed without an issue.
Windows Server 2008, Windows Firewall and SQL 2005http://CameronFuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1427.entry | Comments Windows Server 2008, Windows Firewall and SQL 2005 Several of us were building out a POC Configuration Manager 2007 environment which had a single ConfigMgr server and a separate SQL 2005 database (shared with Operations Manager). The ConfigMgr server was running on ConfigMgr 2007 SP1/Windows Server 2008 and the SQL Server was running SQL 2005 SP2/Windows Server 2008. ConfigMgr server would not pass the prerequisite checks because it could not connect to the SQL Server. Prior to making any changes, the ConfigMgr server could ping the SQL Server but we could not connect via the SQL Administration tools. Debugging on this consisted of pinging the SQL server and trying to telnet (we had to install the feature through the Server Manager application on the ConfigMgr server so that we could use the telnet to test this connectivity). We were unable to connect on port 1433 via telnet from the ConfigMgr server, and validated that the SQL server could connect to itself with “telnet localhost 1433”. So, logically enough it looked like the Windows Firewall was blocking the connection to the SQL Server from the ConfigMgr Server. As a background, the Windows Firewall on Windows Server 2008 is activated by default as shown below.
To attempt to get communication, we did a stop of the Windows Firewall service on the SQL Server (net stop “Windows Firewall”). Little did we know what a mistake this was. Once this change was made we could no longer ping from the ConfigMgr server to the SQL Server. The SQL Server could however ping other systems on the network. So communication to the SQL Server was restricted (inbound) but communication from the SQL Server was not restricted (outbound). Once we started the Windows Firewall service on the SQL Server, we could ping from the ConfigMgr server to the SQL Server. With the Windows Firewall service running on the SQL Server we did a port scan against the SQL Server (using the Advanced Port Scanner which is a great tool). The results were five open ports which were detected as shown below (ports 53, 88, 135, 139 and 445).
After we started the Windows Firewall service on the SQL Server we re-ran the port scan against the SQL Server. The results confirmed a sinking suspicion. No open ports were detected as shown below when the Windows Firewall service was shut down.
When we changed the firewall state to off (see the first graphic for where this is turned on/off), we could then successfully ping from the ConfigMgr server to the SQL Server and we could now connect on port 1433. As additional roles are added in Windows 2008, changes are made to the firewall rules to allow the new role to function. SQL 2005 is not a role, and doesn’t make firewall changes so this makes sense. One of the big benefits to Windows Server 2008 is the new firewall functionality, so it is not a optimal to shut down this function. To get SQL 2005 to be able to be remotely connected to via the ConfigMgr server we created a new Inbound rule which allowed port 1433 access for TCP as shown below (the new rule is highlighted below).
Once the new rule was in place, we could connect from the ConfigMgr server to the SQL server on port 1433 even when the Windows Firewall was running. Lessons learned: 1) Do NOT stop the Windows Firewall service either via commandline (net stop “Windows Firewall”) or via the services (services.msc). Stopping this service while the firewall is still active locks down all inbound communication. If you need to disable the Windows Firewall use the Server Manager application –> Configuration –> Windows Firewall with Advanced Security, right-click and go to properties. Change the firewall state to Off. 2) For SQL 2005
Servers running on Windows 2008, either disable the Windows Firewall (not
preferred) or add a rule which allows inbound access to port 1433 (recommended)
so that remote servers can communicate with the SQL Server database. If
instances are used, a rule will need to be defined for the port of each
instance.
|
||||||||||||
|
|
Invite as friend
