During computer discovery in a SCOM 2012 R2 management server, I’ve noticed that it is takng forever to complete and doesn’t actually discover anything and hangs.
When I take a closer look on active Alerts I noticed below.
If the SQL Broker of the OperationsManager database is not running the Discovery wizard cannot be completed and it was the culprit here. Let’s see how to fix this issue.
Verify SQL Broker status
- In the SQL Server Management Studio select the OpsMgr Database.
- Right Click the database and select New Query
- Execute the below SQL statement
SELECT is_broker_enabled FROM sys.databases WHERE name = ‘OperationsManager’
Check the return value. 0 means SQL Broker is disabled. 1 means SQL Broker is enabled.
How to enable the SQL Broker on OperationsManager Database
Stop the SCOM SDK Service & Health Service on all management servers in the management group. This will close any active connections to the OperationsManager database. I would suggest stopping all the services related to SCOM.
- Right Click the database and select New Query
- Execute the below SQL statement.
ALTER DATABASE OperationsManager SET ENABLE_BROKER
- If all is fine you should see a successful output.
- Close SQL Server Management Studio.
Now check whether the SQL Broker is running as described above.
Some articles that I’ve found states running a third SQL query against the OpsMgr database to change the database to Single User Mode.This should be executed before SET ENABLE_BROKER SQL statement.
ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
It will result below error once you enable the broker.
Msg 5011, Level 14, State 5, Line 1
User does not have permission to alter database ‘OperationsManager’, the database does not exist, or the database is not in a state that allows access checks.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
But I skipped that part. The cause is it will create deadlock situation where you will have to run SQL Profiler and stop all processes related to OprMgr database. Also you will have to close SQL Server Management several times.
To monitor servers using SCOM 2012 R2 Microsoft Operations Manager Agent should be installed in the servers. But sometimes you may have noticed agent installation via push installation/automatic discovery fails.
I’ve setup SCOM 2012 R2 in a customer environment which has below setup.
- 2 SCOM Servers in a child domain (i.e abc.y.com)
- 10 Windows Servers in the same child domain need to monitored
- 5 Windows Servers in the parent domain (i.e y.com) need to be monitored
The push installation was successful for the servers in the child domain but not in the parent domain. When I took a closer look I noticed that inbound ports except port 5723 has restrictions in the parent domain servers.
SCOM Management servers use below ports to communicate with MOM Agent. All these are inbound on the servers that has MOM agent installed.
|RPC endpoint mapper
|RPC/DCOM High ports (2000/2003 OS
||1024 – 5000
|RPC/DCOM High ports (2008 OS)
|NetBIOS name service
|NetBIOS session service
|SMB over IP
SCOM uses RPC & SMB to copy the agent installation setup files to the server that needs to be monitored. Therefore TCP/UDP ports 135, 137 & 445 needs to be opened.
In my case these ports are not opened in the root domain. Therefore I proceeded with manual agent installation of the failed servers. Although the agent installation was successful still those servers was not visible on the management server.
If you are doing manual agent installation you need to configure the security settings of the management server in the Operations Console by visiting Administration > Settings > Security > Tick Review new manual agent installations in pending management view radio button.
This will list the manually installed agents in the Pending Management section so that you can review and approve. Also if you want to automatically approve the agents tick the Automatically approve new manually agent installed agents check box.
If you are just messing with Azure AD for testing sometimes you want to delete any directories that you created or subsequently on boarded (i.e Office 365). Have you ever faced a scenario where you cannot delete a directory? Let’s see why is that.
You can delete an Azure AD as long as it meets below prerequisites. This ensures that users will not impacted by such action.
There cannot be any active Multi-Factor Authentication Providers linked to the directory that you are going to delete.
You have to delete all the users except the global administrator of that directory prior you attempt to delete the directory itself. No need to delete any groups. You can refer my previous blog post on hoe to delete orphaned Azure AD accounts if you need any instructions.
All applications associated with that directory should be removed first. Remember if you have added an application from the Azure AD Application Gallery (i.e SalesForce) you cannot delete the directory at all. This is a current limitation on Azure AD which Microsoft promises a fix soon.
If your directory is associated with any of the Microsoft Online Services such as Office 365, Intune or Azure AD Premium you cannot delete the directory from the portal. This is chicken and egg problem since those services use that directory for authentication. If so badly wants to do that, you’ll have to contact Microsoft Support to get that done for you and it is a lengthy process.
So remember before you start cursing Azure Team, keep in mind these little tips. I for one personally want to get rid of Scenario 3 & 4 because sometime customers are doing mistakes for signing up for multiple identities with different Microsoft Online Services and later suffer from dilemma of deletion.
Deleting an Azure AD is irreversible. So think twice before you pull the plug.