Account Lockout source process / application

Hello There,
I am using "Account Lockout Status" and also "Netwrix Account Lockout Examiner" which is really helpful.
I have a situation one of the user account is getting locked out everyday i tried to trace the source but in all the cases it shows
the source as TMG (which is the gateway for email & lync access) through internet.
I am suspecting the account lockout source is the user's machine but i want to see which process is triggering this.
How can i check the process name which is causing account lockout on the source machine itself?
please suggest.
Regards,
Maqsood
Maqsood Mohammed Senior Systems Engineer MCITP-Enterprise Admin & ITILv3 Foundation Certified

1. Run this command:
rundll32 keymgr.dll,KRShowKeyMgr
2. Backup the stored credentials using the Backup button. Then, remove them.
If the problem continues, we need to enable audit policies and analyze event log to troubleshoot this problem. For more information,
please refer to:
Troubleshooting Account Lockout
http://technet.microsoft.com/en-us/library/cc773155(WS.10).aspx
Account Lockout and Management Tools
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465
Hope below link helps.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/8c0e9442-6df6-43b0-8b50-bd44f53dfdea/my-account-is-getting-locked-out?forum=winserversecurity
Regards,
Manjunath Sullad

Similar Messages

Random Account Lockout (How to trace source?)

In Windows 2003 server native domain environment: XP Pro machines have no issues, but all ~10 PCs that have Win7 Pro (in different offices) have their domain accounts locked out randomly throughout the day. Workstations have no passwords listed in credentials
management.
Suspect it is something on the workstations that is sending incorrect logon and triggering the invalid password lockout limit on domain policy. Found MSFT tools to trace in XP, but nothing for Win7. Does anyone know how to use Procmon or similiar tool to
trace such source on the workstations? Thank you.
(Procmon.exe from systernals)

Hi,
The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.
We can run the LockoutStatus.exe on domain controller to identify and investigate the account lockout issue.
Troubleshooting tools:
By using this tool, we can gather and displays information about the specified user account including the domain admin's account
from all the domain controllers in the domain. In addition, the tool displays the user's badPwdCount value on each domain controller. The domain controllers that have a badPwdCount value that reflects the bad password threshold setting for the domain are the
domain controllers that are involved in the lockout. These domain controllers always include the PDC emulator operations master.
You may download the tool from the link
Download Account Lockout Status (LockoutStatus.exe)
http://www.microsoft.com/downloads/details.aspx?familyid=D1A5ED1D-CD55-4829-A189-99515B0E90F7&displaylang=en
Once we confirm the problematic computer, we can perform further research to locate the root cause. Actually, there are many possible
causes for bad password, such as cached password, schedule task, mapped drives, services, etc. Please remove the previous password cache which may be used by some applications and therefore cause the account lockout problem.
Troubleshooting steps:
1. Click Start, click Run, type "control userpasswords2" (without the quotation marks), and then click OK.
2. Click the Advanced tab.
3. Click the "Manage Password" button.
4. Check to see if these domain account's passwords are cached. If so, remove them.
5. Check if the problem has been resolved now.
If there is any application or service is running as the problematic user account, please disable it and then check whether the problem
occurs.
For your convenience, I'd like to list the common troubleshooting steps and resolutions for account lockouts as the following:
Common Causes for Account Lockouts
To avoid false lockouts, please check each computer on which a lockout occurred for the following behaviors:
Programs:
Many programs cache credentials or keep active threads that retain the credentials after a user changes their password.
Service accounts:
Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers.
If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using
the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the service control manager to use the new password and avoid future account
lockouts.
Bad Password Threshold is set too low:
This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower
than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing
Account Lockout Settings for Your Deployment" in this document.
User logging on to multiple computers:
A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with
the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they
request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log
off and back on.
Stored user names and passwords retain redundant credentials:
If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant
because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information about Stored User Names and Passwords, see online help in Windows XP and the
Windows Server 2003 family.
Scheduled tasks:
Scheduled processes may be configured to using credentials that have expired.
Persistent drive mappings:
Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when
they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails
when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, please type net use /persistent:no. Alternately,
to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive.
Active Directory replication:
User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should
verify that proper Active Directory replication is occurring.
Disconnected Terminal Server sessions:
Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information.
A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that
the source of the lockout comes from a single computer that is running Terminal Services.
Service accounts:
By default, most computer services are configured to start in the security context of the Local System account. However, you can
manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service
may lock out the account.
Internet Information Services:
By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access
to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache. For more information, see "Mailbox Access via OWA Depends on IIS Token Cache" in the
Microsoft Knowledge Base.
MSN Messenger and Microsoft Outlook:
If a user changes their domain password through Microsoft Outlook and the computer is running MSN Messenger, the client may become locked out. To resolve this behavior,
see "MSN Messenger May Cause Domain Account Lockout After a Password Change" in the
Microsoft Knowledge Base.
For more information, please refer to the following link:
Troubleshooting Account Lockout
http://technet.microsoft.com/en-us/library/cc773155.aspx
Account Passwords and Policies in Windows Server 2003
http://technet.microsoft.com/en-us/library/cc783860.aspx
Hope this helps!
Novak

Need to find out which application is making an frequent account lockout in AD

Hi ,
In my environment two of the user accounts are having an frequent account lockout.
We have found that the account lockout was happening in their own machines with the help of the event logs in the domain controllers.
Please tell us how do we find that which application on their machines are making an frequent account lock with the help of event logs else do we have some other options.
All of your suggestions are much appreciated.
Thanks & Regards S.Nithyanandham

Usage of Microsoft ALtools( https://www.microsoft.com/en-us/download/details.aspx?id=18465 ):
LockoutStatus application
 Run LockoutStatus.exe and choose File > Set target > Define “Target User Name”
and “Target Domain Name”
Tool will show you user with its “User State” (Locked/Not Locked), time when
account was locked (Lockout Time) and will allow you to Unlock Account if you
right click output string.
EventCombMT application
 This tool gathers specific events from Windows event logs of single or several
different servers to one central location.
 Run EventCombMT.exe > Right Click on “Select to search” field >Choose “Get DCs
in Domain” > Mark your Domain Controllers for search> Select “Security” log file >
Type “4740” in the “Event IDs” field > Choose “Success Audit” Event type > Click
“Search” > Wait for “Matching Events Found” counter to show some values and
click “Quit”
 In the opened window investigate file or files named by your domain controllers
names. You should be able to determine the originating system where lockout
happened by searching for “Caller Computer Name”
Aloinfo application
 This tool has 2 purposes:
 To display all user account names and the age of their passwords run cmd >
change directory to the one where ALtools were extracted > type @powershell >
Enter > type “./aloinfo.exe /expires /server:DC | out-file C:\temp\expires.txt” >
Enter
 To display credentials used for running services or for mapping network drives
run cmd > change directory to the one where ALtools were extracted > type
@powershell > Enter > type “./aloinfo.exe /stored | out-file C:\temp\stored.txt” >
Enter
You may also enable Netlogon logging on DC through command shell:
nltest /dbflag:2080ffff
Netlogon.txt file is created in %systemroot%/debug directory
Just don't forget to turn it off after investigation :) nltest /dbflag:0
Or you can use
Netwrix Account Lockout Examiner to troubleshoot account lockouts, it's free.
--- Jeff (Netwrix)

Getting user account lockout continuosly

I am getting lockout continuosly for one account. I tried reconfiguring user profile and system restart. But still user account lock out coming..
I enabled audit logs and found failed logs. In that i am getting caller process id as 0x1a8.
I installed procmon, in that PID coming in numbers..
How to convert caller process id into PID or any other way to find which application that process is related to..

You could download the Account Lockout Status tool to get more information where the source is.
http://www.microsoft.com/en-us/download/details.aspx?id=15201

Active directory account lockout issue

I have 1 main AD server which is on windows 2003 R2 and all users are authenticated from this server and second ADC i.e backup ADC which is on windows 2003 R2, we have 3rd ADC on windows 2008 R2 which is created for Exchange 2010 on windows
2008R2,
Users are getting Account lock out issue randomly.
Can any one help on this.

Hi,
You can start with the below threads to see if you have prepared to determine lockouts sources.
http://technet.microsoft.com/en-us/library/cc773155(v=ws.10).aspx
http://blogs.technet.com/b/heyscriptingguy/archive/2012/12/27/use-powershell-to-find-the-location-of-a-locked-out-user.aspx
Use Lokoutstatus from Altools (http://www.microsoft.com/en-us/download/details.aspx?id=18465) then check the source DC where lockouts are being reported. Use the event viewer on
that DC and look for "failure audits" for that particular user acocunt or during that time frame reported on lockoutstatus. Use the event description to find the source workstations/server where the lockout is coming from and verify that server for
any (disconnect RDP sessions, credentials manager, services running with domain accounts,applications,etc).
Hope this helps.
Regards,
Calin

Account lockout problems

Hi,
I've a curious problem with account lockouts. I've read a lot of topics and pages but I can't identify the reason for this problem.
We have setup a new AD and moving the users step by step. It's not a migration with ADMT, we create complete new accounts, move the mailbox & user data manualy and move the workstation from the old to the new domain.
We have moved around 100 users and with around 5 of them, I've account lockout problems. While working, the account gets lockout.
I installed NetWrix Account Lockout Examiner and set the security settings as required. If the account gets lockout the workstation field is everytime empty. If I examine on DC or the users worksation, the result is mostly like this:
from ::ffff:192.168.**.*** (\\DC2) at 09.01.2014 08:46.26
fom 10.0.*.* (\\UsersWS) at 09.01.2014 08:46:26
+ from ::ffff:10.0.*.* (\\UsersWS) at 09.01.2014 08:39:26
Reason: Unknown user name or bad password
Logon Type: CachedInteractive
So, the first entry seems to be a "valid" login failure, but after that, the next two are curious.
I checked the security log on DC2 and found 2 entries for that time / user:
Source: Microsoft Windows-Security-Auditing
ID: 4771
Kerberos pre-authentication failed.
Client: UserWS
Ticketoptions: 0x0
Errorcode: 0x18
Type: 2
Source: Microsoft Windows-Security-Auditing
ID: 4740
A user account was lockout.
Caller Computer Name:
Is the problem realy UserWS? I'm not sure because caller computer name is empty. Typicaly things like password store etc. are checked.
Could it be the exchange server? User has a smartphone syncing his mailbox. But the device does not show any error.
After a successful login, the bad password count should be reset to 0, but it seems that it keeps 1 or 2 so that the account gets lockout after one auth failure
I'm thanksful for any hint.

Smartphones and similar devices are common causes for account lockouts. You need to check applications running on them that require an AD authentication and be sure that you are using the correct password.
Paul have created a great article about how to troubleshoot account lockout issues: http://blogs.dirteam.com/blogs/paulbergson/archive/2012/04/23/user-account-lockout-troubleshooting.aspx
This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
Get Active Directory User Last Logon
Create an Active Directory test domain similar to the production one
Management of test accounts in an Active Directory production domain - Part I
Management of test accounts in an Active Directory production domain - Part II
Management of test accounts in an Active Directory production domain - Part III
Reset Active Directory user password

Account Lockout issue between Apple devices and Exchange 2003

I have been having an ongoing issue for a couple of months with a few different users Apple devices locking out their accounts in AD when they try to authenticate to ActiveSync. This doesn't happen every time they authenticate, it seems to be random,
while the rest of the time they have access to their email. It might occasionally happen with an Android, but not on a repetitive basis like this.
Primarily this has been four different iPads, running different versions of iOS, and an iPhone running the latest release of iOS 7. Other iPhones and iPads function without having the problem, including iPhones on iOS 7.
The user accounts in question are set to never have their passwords expire, but again, they aren't the only users that are set like this, and those other users, even with Apple devices are not having the same problem.
I used NetWrix to trace out the source machine, which is my Exchange 2003 server and times, and I've checked the W3SVC1 log file, and come up with the following as an example with identification details masked:
<internal IP>, <Domain\Username>, 4/30/2014, 8:10:04, W3SVC1, <ServerName>, <internal IP>, 15, 329, 3367926, 200, 0, GET, /exchange-oma/<[email protected]>/NON_IPM_SUBTREE/Microsoft-Server-ActiveSync/iPad/ApplV50462*****/eb53cd5d5b9fcf40****************-20ef44,
As I was typing this, the owner of the iPad from the log file above came by my desk, so I asked a couple more questions. He's never had another iPad, it's a gen 1, and he's never updated the iOS on it. I know one of the other iPads in question
has the most up to date iOS, and the other one is brand new, replacing one that was broken, but the owner of that one had the same issue on a 3 year old iOS.
There is nothing special about the user accounts, no special privileges or restrictions.
Has anyone encountered this before? Exchange 2003, Server 2003 in a 2008 domain. Promotion to the 2008 domain was 2 years ago.

Hi Brian,
I am so sorry for the delay.
Do you have any progress by now?
Since there are lots of devices which use user accounts to log on, failed logon attempts on these devices could be the cause for account lockout.
If this issue persists, I suggest you refer to these troubleshooting articles below:
Troubleshooting account lockout the PSS way
http://blogs.technet.com/b/instan/archive/2009/09/01/troubleshooting-account-lockout-the-pss-way.aspx
Troubleshooting Account Lockout
http://technet.microsoft.com/en-us/library/cc773155(v=WS.10).aspx
In addition, you can also get efficient support at Active Sync forum below:
http://social.technet.microsoft.com/Forums/exchange/en-US/home?forum=exchangesvrmobilitylegacy
Best Regards,
Amy

Event 4740 Not Logged for a Single Account Lockout

Domain Functional Level: 2003
PDC Emulator: 2008 R2
Lockout Origin DC (also the RADIUS server): 2003 R2
For quite a while now I have been relying on Event 4740 on the PDC Emulator to track account lockouts. Usually when the RADIUS server causes an account lockout, the Caller Computer Name is blank in the Event 4740. This usually tells me that our
Cisco WLAN Controller caused the lockout.
Our Default Domain Policy is set to audit Account Logon Events for failure, Account Management for success/failure, and Logon Events for success/failure (plus numerous other things).
This time there is no Event 4740 for this account lockout and I can't figure out why. The events are there for other lockouts several minutes before or after this one. Windows just hates me so it decided to skip this one. The main reason
this is a problem is because I just set up Scheduled Task on the PDC Emulator, triggered by Event 4740, to run a PowerShell script that will provide the help desk with a report for each account lockout, even parsing the IIS logs on the Client Access Server
to identify which ActiveSync device caused it. Of course the week after I announce that, Windows decides not to log one.
Using LockoutStatus.exe I determined that the Origin DC for the lockout was the RADIUS server.
NetLogon debug logging is enabled on the RADIUS server, however I took a nap today after being let out of work early for the holiday so by the time I checked the netlogon.bak file it had already been overwritten with newer data.
There was, however, an Event 644 locked on the RADIUS server (pasted below with domain/computer/user details edited for privacy). I don't even know where to start as far as trying to prevent this from happening again. Anyone have any suggestions?
Within the next couple months I will spin up a 2012 RADIUS server and a separate 2008 R2 DC to replace the 2003 multipurpose server, but it's not high on my boss's priority list so it's a tough sell considering the WLAN is functional right now.
Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 644
Date: 12/31/2014
Time: 10:00:35 AM
User: NT AUTHORITY\SYSTEM
Computer: DomainControllerAndRadiusServer
Description:
User Account Locked Out:
Target Account Name:
LockedOutUser
Target Account ID:
DOMAIN\LockedOutUser
Caller Machine Name:
CISCO
Caller User Name:
DomainControllerAndRadiusServer$
Caller Domain:
DOMAIN
Caller Logon ID:
(0x0,0x3E7)
For quite a while now I have been relying on Event 4740 on the PDC Emulator to track account lockouts. Usually when the RADIUS server causes an account lockout, the Caller Computer Name is blank in the
Event 4740. This usually tells me that our Cisco WLAN Controller caused the lockout.
For quite a while now I have been relying on Event 4740 on the PDC Emulator to track account lockouts. Usually when the RADIUS server causes an account lockout, the Caller Computer Name is blank in the
Event 4740. This usually tells me that our Cisco WLAN Controller caused the lockout.
For quite a while now I have been relying on Event 4740 on the PDC Emulator to track account lockouts. Usually when the RADIUS server causes an account lockout, the Caller Computer Name is blank in the
Event 4740. This usually tells me that our Cisco WLAN Controller caused the lockout.

Hi,
I suggest you use Auditpol command to check the current auditing status on Domain Controller.
You can type this command below:
Auditpol /get /Category:Logon/Logoff
If the Account Lockout subcategory is set to no auditing, please use /set option to enable auditing:
Auditpol /set /Subcategory:”Account Lockout” /Success:enable /Failure:enable
More information for you:
Auditpol
http://technet.microsoft.com/en-us/library/cc731451.aspx
Best Regards,
Amy
Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

The Financial Accounting program cannot process the document.

THIS PROBLEM IS COMING AFTER THE BILING AND THE ACCOUNTING DATA IS NOT CREATED FOR THIS PROBLEM
CAN ANY ONE SOLVE THIS PROBLEM
GURUS PLEASE HELP
No account is specified in item 0000001005
Message no. F5670
Diagnosis
No account was specified for account type "S" in item "0000001005" of the FI/CO document.
System Response
The Financial Accounting program cannot process the document.
Procedure
A system error has probably occurred in the application you called up. Check the data transferred to item "0000001005" of the FI/CO document.
WITH REGARDS
SUBRAT

Hi,
I think this is due to problem in acount determination.
Please check VKOA
Best Regards
Ashish Jain

Activesync account lockout issue

Few days back a user raised a concern of frequent account lock out in our environment. When I checked the user, I found an old device for the user which I blocked and removed. The user continued to face the problem. Then I disabled the activesync feature
for the user, but still the some old device is hitting IIS for the user and the account is getting locked. The problem is that there is no trace for the device except "Android/4.2.2-EAS-1.3" for the user and also, the same device is not present for
the in exchange. I have tried to detect the device using MFCMapi, but no such android device is present for the user. Is there any way to detect and delete this device which is causing the lockout ? And also, I want to know how a mobile device behaves to IIS
if we disable the activesync feature for a user ?
Any suggestion will be helpful for me. Thanks.

Hi
In addition to above you can check the below things
I will suggest you to run the following command to see the devices connected and active
Get-ActiveSyncDeviceStatistics -Mailbox username
Also check if the user has any mobile device connected through any other Mobility platform BB, Good Messaging, etc., which might be causing this issue
Block out the originating IP address on the firewall in front of the Exchange server
Also Logon to the exchange server and look for audit security event logs to find out the source
Also you can use this script to find the old mobile devices
http://blogs.technet.com/b/heyscriptingguy/archive/2014/01/18/avoid-account-lockout-use-powershell-to-find-old-mobile-devices.aspx
Remember to mark as helpful if you find my contribution useful or as an answer if it does answer your question.That will encourage me - and others - to take time out to help you Check out my latest blog posts on http://exchangequery.com Thanks Sathish
(MVP)

Accounts not found in Application ICMatching

What accounts I need to give in ICBOOKING busiess Rulu:
Parent Matching Account ,Type, Other Destination Dimension, Booking Destination Data Source, Maxbooking amout, Debit Account, Debit Flow, Debit Intco, Credit account, Credit flow, Credit IntCo
Please guide me what I need to fill the accounts in business rulses:
When I run the ICBooking Pakage its showing the Error: Accounts not found in Application ICMatching.
Regards,
GURU

Hi Guru,
Please have a look at the below link from help.sap:
http://help.sap.com/saphelp_bpc75/helpdata/en/b4/918ba15cd3499b9d763bb45d5a29de/content.htm
Even though its from BPC MS, the tables fields are almost the same. You will get the information about each of the fields.
Hope this helps.

FAGLGVTR= No accounts to be processed have been found

HI Expert,
I have two company code A & B, B copy form A.
When I run FAGLGVTR (balance carryforward) at company code B for 2012. I get the message "No accounts to be processed have been found". But company code A work the tcode is fine.
How can I debug this ?
Ps.The post period is open from 2011/12 to 2012/01.

hi
firstly, you need to check whether you have copied all accounts from source company code. (fs00)
then you probably need to check the balance of previous year, if you just copy the company code, no balance is copied in fact.
(FAGLB03 - Display Balances (New) )
best regards, Lawrence

DSEE user account lockout notification

I am a new administrator for an Oracle Directory Server Enterprise Edition 11g installation. Currently we have an account lockout policy in place to lock an account after 20 failed attempts. Is there a way within the DSEE application to set it up to notify me by email when an account gets locked? If there is not a way to configure the application to send notification, what would be the best way to accomplish this task?
Thank You.

Hello,
There is no notification email or similar notif mechanims. Such feature is available with Oracle Unified Directory though.
I would say the simplest way would be to parse access logs and search for errors like
[09/Jun/2009:16:15:03 +1000] conn=2946 op=0 msgId=1 - BIND dn="uid=testuser,ou=people,ou=unix,dc=..." method=128 version=3
[09/Jun/2009:16:15:03 +1000] conn=2946 op=0 msgId=1 - RESULT err=53 tag=97 nentries=0 etime=0, Account inactivated. Contact system administrator.
Note: This is a old dsee log sniplet, so exact message might vary slighly.
HTH
Sylvain
When closing a thread as answered remember to mark the correct and helpful posts to make it easier for others to find them

Help needed, M getting this message sandbox environment error no test user account, when downloading any application from iTunes, friend told me to sign out and sign in iTunes it might solve the problem but instead I cannot login I to my itune account.

Help needed,
I am getting this message sandbox environment error no test user account, when downloading any application from iTunes, friend told me to sign out and sign in iTunes it might solve the problem , and i triyed it but still I cannot login I to my itune account. Same message keeping. Popping up, this problem started supricly today.

Take a look at the instructions here.
http://www.technogal.net/2012/03/this-is-not-test-user-account-please.html

Shopping cart sourcing process in SRM 7.0

Hi gurus
I want to run a sourcing process in Classic scenario but my question is if it is possible.
1. Requester creates an SC XX to order a service
2. The SC goes to Purchasers worklist for sourcing
3. The Purchaser make an Rfx with data from the SC to different vendors
4. The vendors log in to create response to the RFx
5. The Purchaser select the best offer and creates a contract
Now the question is in the following process.
6. Is it possible for the Purchaser to assign the contract to the original SC XX that was created?
7. The SC is transferred to backend to create a PO
Hope someone can help me in this issue
Thanks

Hi,
No. As SC that you have selected in carry out sourcing would then be used to create RFx.
You have to create new SC & assign contract to it.
SC can be transferred to back end, then it would convert to PR. (depends on configuration).
I hope it helps.
Regards,

Account Lockout source process / application

Similar Messages

Maybe you are looking for