NS 7 filters not updating
I have a problem with a new install of NS 7 where none of the filters are updating despite running the resource update schedule.
When running the resource update I see numerous instances of the following error
Description: ResourceAssociationType failed to load and is ignored:
Failed to initialise DefaultDestinationRMoResourceTypeItem.
I do not have .NET 3.5 SP1 installed as has been mentioned in other posts.
The following custom filter does work for me though.
select vc.guid, vc.name
from vcomputer vc
where vc.[ismanaged] = '0'
My import was done via AD.
Strangely, when I go to the agent push and attempt to select computers I get an error saying I must run discovery first. This is despite the fact I have done an AD import and my computers are clearly visible in org views and groups.
I pushed an agent out to a machine by manually typing it's name in to the wizard. this machine then started appearing in filters once the agent has been installed.
I've seen a few posts like this but none with any real resolution, other than to use the custom filter instead, which isn't really a fix in my opinion.
I have a case logged with Altiris support who should be looking at it this morning but if anyone has a quick fix I'd like to hear from you!
Thanks for any replies
Robert
Comments
Robert, I've seen similar
Robert,
I've seen similar messages on a new NS7 install. Did you find a resolution?
Please "Mark as Solution" those posts which resolve your problem - its a free way to give something back to those who contribute their time and knowledge to these forums.
The AD import
will allow you to auto deploy the agent on a schedule (by default to all known computers without the agent), or you should also be able to use the "select computers" button to highlight those discovered via AD or Network Discovery. The discover computers is for domain\net bios discovery only.
Most of the built in filters are designed for machines that are managed [ismanaged]='0', so that is why they are blank. That being said, I've seen some strange things with filters and they don't always update properly.
I've also come to rely heavily on custom queriers, so I'll have to respectfully disagree with the first post, as I find them to be quite useful (although I certainly understand the concern).
Jim Harings
HP Enterprise Services
1st Rule of Connect Club: Mark the post that helped you the most as a 'solution'. 2nd Rule of Connect Club:You must talk about Connect club.
A little late, and unbelieveable...
Robert,
A bit late with this, but it seems this is a known issue with SMP7 and the AD Import. I can hardly imagine how this went unreported and unresolved for this long, but it is reported as corrected as part of SMP 7.0 SP4: AKB 50719, under the section Filters and Resource Targets issues.
Thanks,
Kyle
Symantec Trusted Advisor
For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
SP4 didn't fix it
I have the same problem as the original poster and it isn't fixed under SP4. When I try to push the 7 agent to a selection of guinea pigs I'm asked to do a discovery first. I've already done an AD import and I can see all the PCs in my domain under the 'Windows Computers with no Altiris Agent Installed' filter but it still keeps telling me that I need to do a discovery before I can push out the agent. Like Robert, I can push the agent if I manually type in the name of a machine but obviously there's no way I'll be doing that for 2000 nodes.
I don't want to do an automated roll-out yet as I'm just building an eval NS7 environment with selected nodes before we replace the NS6 agents across the board.
Robert, did you get a fix in the end? Does anyone have a real fix for this?
Working as designed
Personally, I think it's a design flaw then.
Filters do not ever get updated unless they have a policy associated with them, regardless of which update schedule is run.
This is to reduce server load, by not running the SQL for filters that have no policies assigned. However, it truly screws other things up.
Oh...and for the love of God, never use vComputer in a filter! Change it, at least, to vComputerExcludingIPInfo. The SQL behind the vComputer view is incredibly intensive, and if it's in a filter (presuming that filter is attached to a policy), that SQL gets run a lot, and can seriously impact your SQL server performance, and drag down your whole NS if you have a either a lot of resources, or a lot of such filters.
JeffDG - do you have other tables you use?
I just did a quick look through some of our custom filters and noticed we were using vComputer. I've changed it to vComputerExcludingIPInfo, but you give me the impression that even that isn't really a good filter to use.
Do you have any other general recommendations query wise? What would you use to get vComputer info usually?
I'll use the source data
I generally start with vItem. This gives me machine name. You can join that to vresource to get the IsManaged flag.
vAsset has a ton of information in it, including status, asset type, model, and serial number.
Joining Inv_aex_ac_tcpip gets you IP information as well, but without the ugly cost of the "Top 1" query.
Thanks for that Jeff!
Do you mind if I ask how many nodes you are administering?
We have currently have 200 and are moving up to around 1500 once fully deployed over the next 6 weeks (NS6 to NS7 migration).
We have a single NS server running with an Intel Xeon E5335 @ 2.00GHz (8CPUs) and 32GB of RAM. Our database sits on a seperate server with the same CPU and 16GB of RAM (shared with our NS6 database).
Just trying to nail these filters and reports before our workstation base gets bigger.
That said, we ran the same ammount of workstations in NS6 and always used the vComputer view with no real impacts.
I guess if you're running 30,000 nodes it would be much different!
So I did a network discovery
So I did a network discovery overnight and I've been able to push manually to my guinea pigs today. Doing an AD import definitely does not discover machines in a meaningful way.
Would you like to reply?
Login or Register to post your comment.