Anonymous_User Absent Member.
Absent Member.
350 views

AD Passwords not synced fron AD to IDM


Hi,

I had a strange issue.
AD driver running, pwd filters installd. All normal sync worked (at
least from eDir), password synced from eDir to AD but not the other
way.
Had a look in the RL trace when changing a password in AD, nothing, so I
suspected the pwdfilters but they seemd to be fine.

Because windows being windows I had a go at restarting the RL service.
Then it hung in mode "Stopping".
Killed it and started it again.
Then all newly changed password started to flow.
This is a 4.0.2 system on W2k8 R2.

What I am puzzeled about is what could have stoppet/blocked the password
piece of the RL?



Btw, instead of rebooting the whole DC I then googled up this way to
kill a service:
Killing a Windows Service that seems to hang on "Stopping"

It sometimes happens (and it's not a good sign most of the time): you'd
like to stop a Windows Service, and when you issue the stop command
through the SCM (Service Control Manager) or by using the ServiceProcess
classes in the .NET Framework or by other means (net stop, Win32 API),
the service remains in the state of "stopping" and never reaches the
stopped phase. It's pretty simple to simulate this behavior by creating
a Windows Service in C# (or any .NET language whatsoever) and adding an
infinite loop in the Stop method. The only way to stop the service is by
killing the process then. However, sometimes it's not clear what the
process name or ID is (e.g. when you're running a service hosting
application that can cope with multiple instances such as SQL Server
Notification Services). The way to do it is as follows:

Go to the command-prompt and query the service (e.g. the SMTP
service) by using sc:

sc queryex SMTPSvc
This will give you the following information:

SERVICE_NAME: SMTPSvc
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, PAUSABLE,
ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 388
FLAGS :

or something like this (the "state" will mention stopping).
Over here you can find the process identifier (PID), so it's pretty
easy to kill the associated process either by using the task manager or
by using taskkill:

taskkill /PID 388 /F

where the /F flag is needed to force the process kill (first try
without the flag).

Please be careful when you do this; it's useful for emergencies but you
shouldn't use it on a regular basis (use it as a last chance to solve
the problem or to avoid the need of a reboot in an exceptional
situation). It can even be used to stop a service that has the
"NOT-STOPPABLE" and/or "IGNORES_SHUTDOWN" flag set (e.g. Terminal
Services on a Windows Server 2003 is non-stoppable), at least when it's
not hosted in the system process. You can query all this information by
means of the sc command.


--
joakim_ganse
------------------------------------------------------------------------
joakim_ganse's Profile: https://forums.netiq.com/member.php?userid=159
View this thread: https://forums.netiq.com/showthread.php?t=47074

Labels (1)
0 Likes
8 Replies
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM


My first thought would be Windows Firewall.

Thanks,

Bob

joakim_ganse;226500 Wrote:
> Hi,
>
> I had a strange issue.
> AD driver running, pwd filters installd. All normal sync worked (at
> least from eDir), password synced from eDir to AD but not the other
> way.
> Had a look in the RL trace when changing a password in AD, nothing, so I
> suspected the pwdfilters but they seemd to be fine.
>
> Because windows being windows I had a go at restarting the RL service.
> Then it hung in mode "Stopping".
> Killed it and started it again.
> Then all newly changed password started to flow.
> This is a 4.0.2 system on W2k8 R2.
>
> What I am puzzeled about is what could have stoppet/blocked the password
> piece of the RL?
>
>
>
> Btw, instead of rebooting the whole DC I then googled up this way to
> kill a service:
> Killing a Windows Service that seems to hang on "Stopping"
>
> It sometimes happens (and it's not a good sign most of the time): you'd
> like to stop a Windows Service, and when you issue the stop command
> through the SCM (Service Control Manager) or by using the ServiceProcess
> classes in the .NET Framework or by other means (net stop, Win32 API),
> the service remains in the state of "stopping" and never reaches the
> stopped phase. It's pretty simple to simulate this behavior by creating
> a Windows Service in C# (or any .NET language whatsoever) and adding an
> infinite loop in the Stop method. The only way to stop the service is by
> killing the process then. However, sometimes it's not clear what the
> process name or ID is (e.g. when you're running a service hosting
> application that can cope with multiple instances such as SQL Server
> Notification Services). The way to do it is as follows:
>
> Go to the command-prompt and query the service (e.g. the SMTP
> service) by using sc:
>
> sc queryex SMTPSvc
> This will give you the following information:
>
> SERVICE_NAME: SMTPSvc
> TYPE : 20 WIN32_SHARE_PROCESS
> STATE : 4 RUNNING
> (STOPPABLE, PAUSABLE,
> ACCEPTS_SHUTDOWN)
> WIN32_EXIT_CODE : 0 (0x0)
> SERVICE_EXIT_CODE : 0 (0x0)
> CHECKPOINT : 0x0
> WAIT_HINT : 0x0
> PID : 388
> FLAGS :
>
> or something like this (the "state" will mention stopping).
> Over here you can find the process identifier (PID), so it's pretty
> easy to kill the associated process either by using the task manager or
> by using taskkill:
>
> taskkill /PID 388 /F
>
> where the /F flag is needed to force the process kill (first try
> without the flag).
>
> Please be careful when you do this; it's useful for emergencies but you
> shouldn't use it on a regular basis (use it as a last chance to solve
> the problem or to avoid the need of a reboot in an exceptional
> situation). It can even be used to stop a service that has the
> "NOT-STOPPABLE" and/or "IGNORES_SHUTDOWN" flag set (e.g. Terminal
> Services on a Windows Server 2003 is non-stoppable), at least when it's
> not hosted in the system process. You can query all this information by
> means of the sc command.



--
bstumpp
------------------------------------------------------------------------
bstumpp's Profile: https://forums.netiq.com/member.php?userid=2783
View this thread: https://forums.netiq.com/showthread.php?t=47074

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM

On 13.03.2013 15:54, bstumpp wrote:
>
> My first thought would be Windows Firewall.


Yes but why would simply killing the hung dirxml_remote.exe process fix
this?

Joakim didn't mention making any other changes except restarting this
hung process.

Some guesses as to why the remote loader wouldn't stop cleanly.

1. Have you also got the IDM Exchange support configured or installed
(either for managing Exchange accounts or for the powershell capability
added in 402)?

The AD driver shim communicates with this additional service and I'm
pretty sure I've seen the RL get hung up if the service doesn't respond
properly.

2. Did you have the AD remote loader console running but not visible in
the RDP session where you tried to stop the service?

I'm also pretty sure I've seen the RL get confused if the RL console is
visible on another session and you don't close/kill the console first.



--
----------------------------------------------------------------------
Alex McHugh
NetIQ Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support is provided via email.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM

On Wed, 13 Mar 2013 09:14:01 +0000, joakim ganse wrote:

> AD driver running, pwd filters installd. All normal sync worked (at
> least from eDir), password synced from eDir to AD but not the other way.


I wonder if the service lost its ability to read the registry keys. You
might have been able to see this with SysInternals "Debug View".


> Btw, instead of rebooting the whole DC I then googled up this way to
> kill a service:


I use SysInternals "Process Monitor" to kill things. I've yet to find a
process that it couldn't find and kill.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM

It'd be a boon to admins if the vendor would start shipping valid tools
like this instead of the half-baked solution known as "Task Manager". It,
too, can kill dirxml_remote.exe, but it's such a worthless piece of junk
from the early nineties otherwise. Again, windows is not meant to be a
server, and therefore does not have worthwhile tools. As a result those
of us who need to interact with it once in a while have a USB stick of
tools that make it usable (procexp, procmon, cygwin, pscp, putty.... etc.)
but it could all just be there from the start. *sigh*

End rant.
Good luck.
0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Passwords not synced fron AD to IDM

> End rant.
> Good luck.


Ignore Aaron, he had to spend a week or two in NYC and is still grumpy
about it.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM


geoffc;226549 Wrote:
> > End rant.
> > Good luck.

>
> Ignore Aaron, he had to spend a week or two in NYC and is still grumpy
> about it.


Well, I get grumpy if I have to leave my house 😉

Thanks for the suggestions, I will get som sysinternals tools to start
digging.
We don't have the Exchange service on this yet but I did check the
firewall and that is fine and would also not give this behaviour.
One other possibility might be the anti virus thing, I think it is MS
own but the dirxml_remote process is entered there to not scan.
We discovered that on the IDM servers the anti virus stopped the process
after a few days.


--
joakim_ganse
------------------------------------------------------------------------
joakim_ganse's Profile: https://forums.netiq.com/member.php?userid=159
View this thread: https://forums.netiq.com/showthread.php?t=47074

0 Likes
Knowledge Partner
Knowledge Partner

Re: AD Passwords not synced fron AD to IDM

On 3/13/2013 5:34 PM, joakim ganse wrote:
>
> geoffc;226549 Wrote:
>>> End rant.
>>> Good luck.

>>
>> Ignore Aaron, he had to spend a week or two in NYC and is still grumpy
>> about it.

>
> Well, I get grumpy if I have to leave my house 😉
>
> Thanks for the suggestions, I will get som sysinternals tools to start
> digging.


I have seen the Services MSC fail to stop/restart the DirXml_remote
service on Winders before. I just kill the process by hand when it
happens. Usually something else has gone wrong at the same time.

> We don't have the Exchange service on this yet but I did check the
> firewall and that is fine and would also not give this behaviour.
> One other possibility might be the anti virus thing, I think it is MS
> own but the dirxml_remote process is entered there to not scan.
> We discovered that on the IDM servers the anti virus stopped the process
> after a few days.


MCafee seems notorious for this kind of thing.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: AD Passwords not synced fron AD to IDM


geoffc;226557 Wrote:
> On 3/13/2013 5:34 PM, joakim ganse wrote:
> >
> > geoffc;226549 Wrote:
> >>> End rant.
> >>> Good luck.
> >>
> >> Ignore Aaron, he had to spend a week or two in NYC and is still

> grumpy
> >> about it.

> >
> > Well, I get grumpy if I have to leave my house 😉
> >
> > Thanks for the suggestions, I will get som sysinternals tools to

> start
> > digging.

>
> I have seen the Services MSC fail to stop/restart the DirXml_remote
> service on Winders before. I just kill the process by hand when it
> happens. Usually something else has gone wrong at the same time.
>
> > We don't have the Exchange service on this yet but I did check the
> > firewall and that is fine and would also not give this behaviour.
> > One other possibility might be the anti virus thing, I think it is MS
> > own but the dirxml_remote process is entered there to not scan.
> > We discovered that on the IDM servers the anti virus stopped the

> process
> > after a few days.

>
> MCafee seems notorious for this kind of thing.


Yep, the anti-virus just seems to just get worse. It used to be
sufficient to have it ignore the dib-set but now with all the memory
scans we need to also ignore all ndsd and dirxml_remote processes.


--
joakim_ganse
------------------------------------------------------------------------
joakim_ganse's Profile: https://forums.netiq.com/member.php?userid=159
View this thread: https://forums.netiq.com/showthread.php?t=47074

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.