Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Active Directory Import Missing Some Computers From The Import

Created: 29 Jan 2013 • Updated: 13 Feb 2013 | 6 comments
This issue has been solved. See solution.

Hi Everyone

I have an issue. It is the same issue as this https://www-secure.symantec.com/connect/forums/active-directory-import-missing-computers

However I have spoken to the DBA team and they have advised that there might be something else that was done to fix this issue other than just a Repair Database? I think this might be a last resort fix?

The system information:
NS Version - 7.1 SP2 Roll Up V3
NS Server - Server 2008 R2 Standard
SQL DB Server - Seperate server to the NS
 

The issue I have is the following.

I am importing Computers from AD. Most machines are being imported ok. However there are a few that are not being imported into the correct OU folders. The machines seem to be all importing into the 'All Computers' view. But are not being imported into the Active Directory Domains > *Domain* view. The import is bringing all the correct OU folder in but is not importing ALL of the machines into those OU folders. New machines seem to be importing OK.

Lets say an OU folder has 9 machines listed in AD. It is only importing 8 of those machines for some reason. I have checked that the machine is listed as 'Enabled' in Altiris. The machine is coming up in the All Computers view under the Manage > Computers menu.

I have tried a full import from AD. I have also created a new import rule that only imports computers from that particular problem OU folder. I run each and they both bring in only 8 machines instead of 9.

I have done a CHECKDB on that SQL database and it returned no errors.

When I deploy applications and patches I tend to use filters based on OU folders. This causes an issue when the machine isnt in the OU folder. It is ok if I deploy the software via "All Windows XP Machines" or "All Windows 7 Machines" but deploying via OU folders doesnt work due to the above issue.

The logs dont really give me any errors. It just says that there were 9 resources imported OK from the correct OU.

Is anyone out there able to provide any assistance?

I hope I have given enough information on the issue.

Kind Regards

Jason

Comments 6 CommentsJump to latest comment

mclemson's picture

Do you have any restrictions on your rules, e.g. import 'some computers'?  If you have any restrictions, what are they?

If you click the Computer link in the rule (as in Import 'Computer' resources..), is your Source Organizational Units, and is the box checked to Create organizational unit filters?

Have you tried running the rule as a Domain Admin (same box) if your application identity isn't already a domain administrator, just as a test?

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner
intuitivetech.com

oi_son's picture

Hi mclemson

Thankyou for your reply.

There are no restrictions, this is the specific rule I setup just to import from the specific OU folder

Import computer resources from **DOMAIN** starting from **OU FOLDER** and using default column mappings. Import all computers on the specified schedules.

Yes when I click on the Computer Link in the rule it says my source is Organizational Units and the Create organizational unit filters is ticked.

Also the application credentials I am using are Domain Admin.

As I mentioned it imports new machines when I add them to the domain and they are in AD. It just seems to be a handfull of machines that are being imported but just not sorted into the OU folders the same as they are in AD.

Any other ideas?

mclemson's picture

I'm pretty well stuck if a domain administrator runs the task and you're running a full import outside of business hours and the logs say it's fully successful for a given OU.

Mike Clemson, Senior Systems Engineer, ASC
Intuitive Technology Group -- Symantec Platinum Partner
intuitivetech.com

oi_son's picture

OK. This issue has been fixed.

Previously I had tried to delete the problem computer from Altiris and ran the Import From AD. The computer was imported into to All Computers section in Altiris but not into the correct OU folder.

What I had to do was delete the problem computer from the following location in Altiris:

All resource > Organizational views > Default > Assets > Network resource >

Then I also had to remove the other 8 machines that were in the OU folder that the problem computer should have been in.

All resource > Organizational views > Active directory > Domain name > *OU folder that is having issues*

After I removed the problem computer and then the rest of the computers from the problem OU folder I did another full import from AD and the computer was imported along with the other 8.

Thanks guys for your help and input.

The issue has been resolved.

SOLUTION
oi_son's picture

OK. I seem to be having the same issue again with a different OU folder and my above method is not working.

I have noticed a few of my problem OU folders have a " / " in the name something like "Dekstop/Test" or something similar. These OU folders in Altiris seem to be missing all the computers that are listed in AD for that same folder. Some other folders without any slashes "/" are still missing some machines but not all machines.

The Altiris log file is showing that the correct number of machines from that OU are being imported. They just dont appear in the OU folders correctly.

I even tested deleting the actual folder and running the import again, it creates the folder ok but the computers dont show up.

I think I might have to give Symantec another call.

oi_son's picture

I tested this again this morning and the OU folders which DO NOT have slashes "/" in the name have been resolved with the above resolution.

However the OU folders which have the slash in the name would not import the computers properly.

I have been informed that there seems to be an issue with my version of SMP..

http://www.symantec.com/business/support/index?page=content&id=TECH180929

Looks like I might have to upgrade again indecision