Wei Li

My feedback

  1. 2 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    If the workspace is closed, the web service API don’t allow the management group – which is still ‘connected’ from its point of view to do anything.

    If you did re-register the group to a new workspace, anyhow, it should start working again.

    Those errors could be transient – MP’s download is attempted every 10 minutes – how often do you see those errors?
    Have you checked the actual list of MP’s imported in the environment? “Verify if things are working” – procedure 1 here http://blogs.technet.com/b/momteam/archive/2014/05/29/advisor-error-3000-unable-to-register-to-the-advisor-service-amp-onboarding-troubleshooting-steps.aspx

    Also check the MPB’s that come with update rollups are imported (Windows Update does not automatically update those, as explained in the KB article for each rollup)?

    An error occurred while saving the comment
    Wei Li commented  · 

    You maybe right about the errors being transient. Event 55002 has been logged in OpsMgr log since Aug 5, the day I closed the workspace and create a new one, it happens every 5 ~ 6 minutes between 12:13 am and 12:35 am, and between 12:13 pm and 12:35 pm, 10 events per day.
    I did update MPs in OpsMgr that came with UR6 for 2012 R2.
    I checked the list of MPs imported following the “Verify if things are working” procedure, they looked OK to me, not sure how it is helping with diagnosing the issue.
    I'll be on vacation for a while, will check back when I am back.

    Wei Li shared this idea  · 
  2. 34 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Ok, I got this answer from the engineers and confirmed the current limitation – we will have to make a change for this:

    WorkspaceName is used to register the portal DNS, and it should be globally unique.
    We cannot reuse the workspace name now, because we dodn’t yet remove the DNS mapping when we do the CloseWorkspace operation.

    An error occurred while saving the comment
    Wei Li commented  · 

    One more thing, when I log into OMS I noticed that I am end up with a URL like the following after click on the workspace I want to get into,

    https://***workspacename***.portal.mms.microsoft.com/#Workspace/overview/index

    The ***workspacename*** part is my workpace name. So if a name is in URL, it kinda make sense that it has to be unique. I understand that. What I think should happen, is that if you close the workspace, you should still be allowed to reuse it as the "close workspace" should 'unocuppy' the URL as well (if you know what I am talking about).

    An error occurred while saving the comment
    Wei Li commented  · 

    Oh, I did not expect response this fast. Not sure how to post screenshots, but here is how you can replicate the issue. BTW, what I was trying to do when closing workspace is to get rid of all the data and start from scratch again.
    1. create a workspace with a name, say 'testwkps1"
    2. close it
    3. try create a new workspace with same name, when you tab out of name field, it will turn red with no error msg, you just can't go to next step unless you give a name that is 'unique'.

    Wei Li shared this idea  · 
  3. 44 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    In the current implementation, Management groups CAN already be removed, but only once they are ‘stale’ == have not reported ANY data for >14days, the link to remove will appear.

    The number of Directly reporting agents in ‘settings’ page is the actual number of servers registered, but the drill down will take you to search (where servers presence is inferred from the data).

    We will be working on options to de-register directly connected servers, similarly to we offer for SCOM management groups.

    An error occurred while saving the comment
    Wei Li commented  · 

    At least making sense to me now:
    I was only talking about servers connected through OI within OpsMgr when I created the post. If I delete a server from Operational Console, all data will get groomed out eventually as OpsMgr stops sending data over for that server. Once that happens, the server will no longer show under "Connected Sources" or any search.

    An error occurred while saving the comment
    Wei Li commented  · 

    Removing servers from Operational Insights in OpsMgr does not remove server from under "connected sources".

    Wei Li supported this idea  · 

Feedback and Knowledge Base