none
MAP 6.0 has been running for 5 days

คำตอบ

  • I would say that an Inventory shouldn’t take more than a day. The key value to look for is the number of failures. The higher the number, the more retries MAP will make and the longer it will take.  Do yourself a favor and cancel this run and start over with a fresh database.

     

    A lot of first time MAP users rush into using it with a very aggressive inventory scan thinking they are saving time by scanning everything at once.  In the end they waste days of effort because MAP is agentless, and thus requires a prepared environment. To be successful with using MAP, I recommend the following troubleshooting techniques, especially in a complex network environment that has configuration issues. The key is to narrow the scope and minimize the variables.

     

    1.       Read Appendix A of the Getting Started Guide

    2.       Read it again, you probably missed something

    3.       Make the necessary changes to the firewalls and ensure the needed services are running

    4.       Create a new database

    5.       Choose one scenario at a time (i.e. Windows computers)

    6.       Choose one discovery method

    a.       The "Windows networking protocols" discovery method is intended for workgroups and NT 4.0 domains only.

    b.      For AD DS, try to narrow the scope as much as possible. Such as 1 domain, or 1 even 1 OU in a domain if you have machines organized into separate OUs.

    7.       Make sure the Windows credentials you enter are in the local machine administrators group for every machine you intend to inventory.  Domain admins are added to that group by default.

    8.       Once you have run the limited inventory discovery, you can generate the hardware summary report to identify what types of failures you are encountering.  View this Wiki article (http://social.technet.microsoft.com/wiki/contents/articles/microsoft-assessment-and-planning-toolkit-inventory-status-messages.aspx) for an explanation of the different types of failures and what they mean.

    9.       Make the necessary adjustments to firewalls/services

    10.   Run the inventory again starting at Step 5.

     

    Considerations:

    ====================

    The MAP inventory process is cumulative:

    When you run an inventory, MAP creates a list. For each machine, a set amount of data is expected to be retrieved based on the scenario chosen. As each machine reaches 100% success for the expected data, MAP flags it and it will not be inventoried again. The exception to this occurs if you run the inventory and select a new scenario that collects additional data. At that point MAP retries the data collection on the machine until it is once again at 100% success.

     

    Retrying from previous inventory:

    Each time the inventory wizard is run, MAP will retry any machines that were attempted previously, but did not reach 100% success. This is done even if those machines are not part of the current list of machines to be inventoried.

     

    The advantage

    This is an advantage because it allows you to limit the scope of each run without losing the data already collected successfully.  As your success increases, you can get more aggressive with the number of scenarios and discovery methods used, until you have a complete inventory.

     

    Eventually, it is possible to get the environment configured so you can run all the scenarios at the same time and be successful on the first run.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    14 กันยายน 2554 2:12
    ผู้ดูแล

ตอบทั้งหมด

  • I would say that an Inventory shouldn’t take more than a day. The key value to look for is the number of failures. The higher the number, the more retries MAP will make and the longer it will take.  Do yourself a favor and cancel this run and start over with a fresh database.

     

    A lot of first time MAP users rush into using it with a very aggressive inventory scan thinking they are saving time by scanning everything at once.  In the end they waste days of effort because MAP is agentless, and thus requires a prepared environment. To be successful with using MAP, I recommend the following troubleshooting techniques, especially in a complex network environment that has configuration issues. The key is to narrow the scope and minimize the variables.

     

    1.       Read Appendix A of the Getting Started Guide

    2.       Read it again, you probably missed something

    3.       Make the necessary changes to the firewalls and ensure the needed services are running

    4.       Create a new database

    5.       Choose one scenario at a time (i.e. Windows computers)

    6.       Choose one discovery method

    a.       The "Windows networking protocols" discovery method is intended for workgroups and NT 4.0 domains only.

    b.      For AD DS, try to narrow the scope as much as possible. Such as 1 domain, or 1 even 1 OU in a domain if you have machines organized into separate OUs.

    7.       Make sure the Windows credentials you enter are in the local machine administrators group for every machine you intend to inventory.  Domain admins are added to that group by default.

    8.       Once you have run the limited inventory discovery, you can generate the hardware summary report to identify what types of failures you are encountering.  View this Wiki article (http://social.technet.microsoft.com/wiki/contents/articles/microsoft-assessment-and-planning-toolkit-inventory-status-messages.aspx) for an explanation of the different types of failures and what they mean.

    9.       Make the necessary adjustments to firewalls/services

    10.   Run the inventory again starting at Step 5.

     

    Considerations:

    ====================

    The MAP inventory process is cumulative:

    When you run an inventory, MAP creates a list. For each machine, a set amount of data is expected to be retrieved based on the scenario chosen. As each machine reaches 100% success for the expected data, MAP flags it and it will not be inventoried again. The exception to this occurs if you run the inventory and select a new scenario that collects additional data. At that point MAP retries the data collection on the machine until it is once again at 100% success.

     

    Retrying from previous inventory:

    Each time the inventory wizard is run, MAP will retry any machines that were attempted previously, but did not reach 100% success. This is done even if those machines are not part of the current list of machines to be inventoried.

     

    The advantage

    This is an advantage because it allows you to limit the scope of each run without losing the data already collected successfully.  As your success increases, you can get more aggressive with the number of scenarios and discovery methods used, until you have a complete inventory.

     

    Eventually, it is possible to get the environment configured so you can run all the scenarios at the same time and be successful on the first run.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    14 กันยายน 2554 2:12
    ผู้ดูแล
  • Hi michael

    I have the same problem - MAP 6.0 is very slow. Now I have download MAP 6.5 Beta, it is better

    this result was created in 10min.

     


    Chris
    25 พฤศจิกายน 2554 7:53
  • I'm running version 6.5 myself, scanning a single subnet (253 IP addresses) and it's going painfully slow... at least it is now at the end.  I can't tell if it's attempting to retry a particular WMI key or what.  I selected just the SQL Server discovery and provided windows & sql native credentials.  It's been sitting here for about an hour.  I DO see the WMI Object Count increasing very slowly... it's at ~ 95,400 and increasing by 1 every 40 seconds.  So I can't tell if it's actually reading values from one machine VERY slowly, or if the counter is incorrect. 
    Looking in the MAP log file, I see an endless sequence (well, 1 every 10 seconds) of these WatchdogThreadPool entries:
     
    <2011-12-14 16:18:38.48 WorkerThread232@DeviceInventoryWorkItem,I> InventoryWorkCallback(Device(GUID={f18d8e11-744a-4471-a168-d223d8c46d8e},DnsHostName='10.10.10.233')) - Device inventory completed. Elapsed time = 00:03:13.126. Collection results: Wmi = Success/39/0/46, Registry = Success/16/0/55, Sql = -/0/0/7.
    <2011-12-14 16:18:38.48 WorkerThread232@InventoryWorkItem,I> WorkCallback() - Completed InventoryWorkItem with description='DeviceInventoryWorkItem(GUID={f18d8e11-744a-4471-a168-d223d8c46d8e},DnsHostName='10.10.10.233')'. Elapsed time: 00:03:13.146
    <2011-12-14 16:18:44.81 TID-230@WatchdogThreadPool,I> UpdateMaxThreadsWatermark() - currentCpuUtil = 2, error = 88, accumulatedCpuUtilError = 0, adjustment = 281.6, countOfThreadsToAdd = 282, maxThreadsWatermark = 288, numThreads = 10, PrivateMemorySize = 443846656, TotalManagedMemory = 45199232
    <2011-12-14 16:18:54.82 TID-230@WatchdogThreadPool,I> UpdateMaxThreadsWatermark() - currentCpuUtil = 1, error = 89, accumulatedCpuUtilError = 0, adjustment = 284.8, countOfThreadsToAdd = 285, maxThreadsWatermark = 288, numThreads = 10, PrivateMemorySize = 444018688, TotalManagedMemory = 35000120
    <2011-12-14 16:19:04.82 TID-129@WatchdogThreadPool,I> UpdateMaxThreadsWatermark() - currentCpuUtil = 1, error = 89, accumulatedCpuUtilError = 0, adjustment = 284.8, countOfThreadsToAdd = 285, maxThreadsWatermark = 288, numThreads = 10, PrivateMemorySize = 443609088, TotalManagedMemory = 35839960
    <2011-12-14 16:19:14.83 TID-129@WatchdogThreadPool,I> UpdateMaxThreadsWatermark() - currentCpuUtil = 1, error = 89, accumulatedCpuUtilError = 0, adjustment = 284.8, countOfThreadsToAdd = 285, maxThreadsWatermark = 288, numThreads = 10, PrivateMemorySize = 443490304, TotalManagedMemory = 36698592
    

    Watching with ProcMon, I see that it's hitting an older server over & over.  This is a Windows 2000 server that's in the middle of the IP address range.  It's hitting it on port 1279 which I assume to be WMI related.  Wireshark decodes this port as "dellwebadmin-2" and the contents related to DCE/RPC requests & responses. 
    Watching the MAP database w/ SQL profiler, I don't see it making any more updates/inserts or changes of any kind... just some login & logout activity.  I'll read a little further on the docs, but hopefully there's a way to filter out this one machine, or possibly just scan the range of IPs before & after it seperately. 
    14 ธันวาคม 2554 23:57
  • Here is our situation. We need to run the tool globally. (One country OU at a time)  We are setting the tool to run during work hours of the country that we are trying to inventory. My understanding is that the tool works this way:

    • Get list from AD OU identified
    • Go to the Machine
    • Try once
    • Try twice
    • Try Thrice
    • Last try
    • Mark entry as a failure - Connection time out etc
    • Go on to the next machine.

    Now if this is true I dont see the point running it for days. Once it tries to connect 4 times in a row it moves and does not go back to retry.

    Now if I based on the response above is this how it should be run?

    • Run Wizard which will get listing of machines from OU identified
    • Go to machine
    • Try once
    • Try twice
    • Try Thrice
    • Last try
    • Mark Entry as a failure - Connection Time Out etc
    • Go to the next machine
    • Run ends( By the way the job doesn;t seem to end till you cancel it. Does cancelling cause issues?)
    • Run the same wizard on another day (lets say same time the following week)
    • Machines that were successfully inventoried will not be attempted
    • Machines that could not be inventoried will automatically be tried
    • Try once, etc
    • Result = inventoried or error.
    • Repeat runs using same database until you get all the items inventoried

    I guess what's throwing me off is that the job runs and runs and will not stop until it is cancelled. At first I thought the MAP tool would run and inventory machines as successful and failure and go back after it has inventoried all the successful machines and try the failed machines until it was able to connect and inventory. This would explain it running for several days to a week or two.

    Any help would be greatly appreciated.

    Dom

    5 มีนาคม 2555 13:27