|
| | | Junior Member
 
Group: Forum Members
Last Login: 7/25/2007 6:29:22 AM
Posts: 16, Visits: 19 |
| | Our Prism-channel suddenly stopped deploying packages to computers in a single OU, called Desktops. Everything worked fine for more than two years, until friday. Then suddenly Task Installation Errors (#2000) started to show up in the deployment logs. Unattended packages are deployed fine, all packages deployed to users belonging to a global group return this error. Some more info in the deployment log shows that certain directories (f.e. "c:\program files\oracle") cannot be created. This sounds like a privilege problem, however all packages are deployed using an account that has administrative privileges on the target machine. And now the strange part: If I create a new OU in the Active Directory, apply all group policies to it that are also applied to the Desktops OU and move a computer to the new OU, deployment works fine. Moving the computer to the Desktops OU, Prism returns the error messages. Moving it back to the new OU: no problems, etc... So the problem is only with this single OU. I have already ruled out privilege issues, group policy, virus scanner and WSUS updates. As far as I know, nothing has changed the last couple of days, except for the number of computers in the Desktops OU, which is over 1100 now. Can it be possible that Prism has trouble reading large amounts of objects in a single OU and starts behaving strangely? Regards, Raymond |
| |
| | | 
Supreme Being
Group: Moderators
Last Login: 10/8/2008 1:15:23 PM
Posts: 655, Visits: 810 |
| | Hi Raymond, We in support have seen very similar behavoir when a "child" folder in the Organizational Groups created by "auto-populate" is enabled for AD created groups, IF the child folder was deleted by mistake. Which if you were adding a number of clients to the OU in AD would most likely have been recreated before it was even noticed it was deleted. We have a script that can check to determine if Parantal-Child relationships for Groups are messed up, however it might have occured. The script is as follows, and you would run this in Query Analyzer with in SQL. SELECT G.GroupID, G.GroupName, PG.ParentGroup AS Grandparent, GPG.GroupName AS [Grandparent Name] FROM dbo.Groups G
INNER JOIN dbo.Groups PG ON (G.ParentGroup = PG.GroupID)
INNER JOIN dbo.Groups GPG ON (PG.ParentGroup = GPG.GroupID)
WHERE PG.ParentGroup IS NOT NULL
AND G.GroupID NOT IN (SELECT GroupID FROM dbo.GroupsIndirectAssignments)
AND G.IsDeleted = 0
AND PG.IsDeleted = 0
AND GPG.IsDeleted = 0 If any "line" is returned then running the following script will fix the Parent-Child relationship. SELECT G.* INTO ##gtemptable
FROM dbo.Groups G
INNER JOIN dbo.Groups PG ON (G.ParentGroup = PG.GroupID)
INNER JOIN dbo.Groups GPG ON (PG.ParentGroup = GPG.GroupID)
WHERE PG.ParentGroup IS NOT NULL
AND G.GroupID NOT IN (SELECT GroupID FROM dbo.GroupsIndirectAssignments)
AND G.IsDeleted = 0
AND PG.IsDeleted = 0
AND GPG.IsDeleted = 0 -- Insert group === grandparent entry in GIA
IF EXISTS (SELECT * FROM dbo.Groups AS g
INNER JOIN ##gtemptable AS i ON (i.ParentGroup = g.GroupID)
WHERE g.ParentGroup IS NOT NULL)
INSERT INTO dbo.GroupsIndirectAssignments (GroupID, AncestorID)
SELECT i.GroupID, g.ParentGroup AS AncestorID FROM dbo.Groups AS g
INNER JOIN ##gtemptable AS i ON (i.ParentGroup = g.GroupID) -- Insert group === indirect parents of object parent
IF EXISTS (SELECT * FROM dbo.GroupsIndirectAssignments AS gia
INNER JOIN ##gtemptable AS i ON (i.ParentGroup = gia.GroupID))
INSERT dbo.GroupsIndirectAssignments (GroupID, AncestorID)
SELECT i.GroupID, gia.AncestorID FROM dbo.GroupsIndirectAssignments AS gia
INNER JOIN ##gtemptable AS i ON (i.ParentGroup = gia.GroupID) DROP TABLE ##gtemptable If when you run the detect script no lines are returned you may want to contact support directly, most likely we'll need to get a copy of the data base. Thanks Support
New Boundary Technologies Support
support@newboundary.com |
| |
| | | Junior Member
Group: Forum Members
Last Login: 7/25/2007 6:29:22 AM
Posts: 16, Visits: 19 |
| | We somehow managed to fix the problem. For some reason, a package of the Java Runtime Environment 1.5.0-07, that was assigned to the Desktops OU, has caused troubles. Anything deployed AFTER this package, returned the errors in the deployment log. I guess that the JRE-package somehow crashed part of the Prism-client that is responsible for adding files and folders using elevated privileges. The funny thing is, we didn't really do anything special to stop this behavior. Al I did was disable the task for a while, and then re-enabled it. Now everything works fine. I guess Prism sometimes works in mysterious ways :-) Greetings, Raymond |
| |
|
|