Message containing password has been suppressed.
-
Thursday, August 16, 2012 7:47 PM
This error is driving me nuts! I never saw this when testing MDT and it has magically cropped up once I put the server into production. It is only intermittent and the other threads on the forums don't really have a concrete reason for why this is displayed. Does anyone know what causes this and how it can be resolved? Sometimes this error is displayed multiple times in one completion notice.
All Replies
-
Thursday, August 16, 2012 9:50 PMDid you check BDD.log to see if you could find an actual error?
-
Thursday, August 16, 2012 10:29 PM
<![LOG[DeploymentMethod = UNC]LOG]!><time="16:23:35.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Validating connection to \\SERVER\Deploy$]LOG]!><time="16:23:35.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Unable to connect to share: The network path was not found. ( 0x80070035 ) , trying to connect without username. ]LOG]!><time="16:23:54.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[<Message containing password has been suppressed>]LOG]!><time="16:23:54.000+000" date="08-15-2012" component="LiteTouch" context="" type="3" thread="" file="LiteTouch"> <![LOG[Unable to connect to \\Server\Deploy$. Sleeping for 5 seconds.]LOG]!><time="16:23:54.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Mapped Network UNC Path Z: = \\Server\Deploy$]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Found Existing UNC Path Z: = \\Server\Deploy$]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Successfully established connection using supplied credentials.]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[DeployRoot = \\Server\Deploy$]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[Property DeployDrive is now = Z:]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch"> <![LOG[DeployDrive = Z:]LOG]!><time="16:23:59.000+000" date="08-15-2012" component="LiteTouch" context="" type="1" thread="" file="LiteTouch">
This section is repeated 3 times throughout the BDD.log -
Friday, August 17, 2012 8:12 AM
it seems it has trouble connecting to the deploymentshare but in the end manages to connect after trying without supplied username and waiting for a few seconds.
are you sure the username and password in your bootstrap.ini or cs.ini are correct?
-
Friday, August 17, 2012 9:35 AM
It may be bit locker issue.
-
Friday, August 17, 2012 2:29 PM
I don't have any credentials in my CS.ini or in the bootstrap.ini
I only enter my credentials during LiteTouch process to connect to the deployment share. Kinda why I'm stumped...
-
Friday, August 17, 2012 2:31 PMI have SkipBitLocker=YES in my CS.ini and it is disabled in the TS... We don't use Bit Locker in my environment.
-
Friday, August 17, 2012 2:34 PM
hmm pretty strange.
maybe the network can't keep up if it only happens sometimes?
-
Friday, August 17, 2012 2:41 PMCould this have something to do with WDS? I never had this error prior to WDS. Is there something I need to configure in MDT? Is there a setting for WDS in the CS.ini?
-
Friday, August 17, 2012 2:48 PM
no settings that i know off at least. you can check if it connects at once if you open a console with F8 in win PE and using the net use command
example: net use G: \\uncpath\deploymentshare$
other thing to try is do enter your info in the boostrap.ini/cs.ini and see if you notice any difference
-
Friday, August 17, 2012 3:19 PMEverything connects and seems to install fine. As I do more and more installs, it is becoming more frequent. It happens pretty much every time.
-
Tuesday, December 25, 2012 1:03 AM
So, what was the cause and how do you troubleshoot this? My bdd.log has the same message in it saying a message containing a password has been suppressed, but I cannot see what it is suppressing.
If it suppresses the reason for the error, then you don't know what is causing the error.
The passwords are working and the account password is not expired or changed or locked and if there was a bad password, the whole deployment would have failed earlier in the process since it would not have access to connect to the deployment share.
Is there another log that will give more useful details of what the problem is?
Even though it says "Success," it still has the bright yellow HTA page as pictured above with 4 messages about suppressed message that makes it appear like there is a problem.
This is a new issue that started after adding images and drivers for laptops. This message is on a Windows 7 desktop PC. I deployed an XP laptop and this yellow page is not displayed.
-
Wednesday, January 09, 2013 1:20 PM
Hello here same error about the "message containing password".
What will be the solution for this?
Thx
-
Wednesday, January 09, 2013 3:17 PM
Still really not sure what is going on. This message is supposed to be displayed so passwords are not show in clear text. But it isn't supposed to show up as errors in the bdd.log. For me, the log seems to show that a connection to the deployment share fails and then connects on the next try MDT makes.
Can anyone else shed light on this?
-
Thursday, February 14, 2013 12:23 PM
It seems this is account-issue.
I have 2 admin-accounts, 1 with the problem, one without this problem.
Any extra security rights needed?
Thx
-
Thursday, February 14, 2013 11:57 PM
It sounds like your machines are booting faster than the network is coming up on them. Try this:
Edit the local 'Always wait for the network at computer startup and logon.' policy under 'Computer Configuration->Administrative Templates->System->Logon'
The registry setting is:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SyncForegroundPolicy"=dword:00000001Then if you don't want to continue with that setting after the build you could then delete "SyncForegroundPolicy"=dword:00000001
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ” How to ask a question that is fixable.
- Proposed As Answer by Ty Glander Friday, February 15, 2013 3:13 PM
-
Friday, February 15, 2013 2:15 AMIt seems similar to a problem we had (unrelated to MDT or WDS) where the user was trying to make two connections to the same fileserver with different credentials. Do you use any external scripts or anything that might be accessing the network with different credentials?
-
Friday, February 15, 2013 3:51 PMThis makes the most sense. What negative effects could we run into if we left this policy on? slower boot times and login times? Is there any other benefits to turning on this policy?
-
Friday, February 15, 2013 4:11 PM
Possible negative effects:
- Login could be longer (up to 600 seconds if there are problems with your group policy)
Benefits:
- Group policy is more robust (it is far more likely to get applied when you wait for the network).
Fix for the possible negative side effect:
If that happes you can set the timeout to something shorter than the default 600 seconds.
To set the timeout to 60 seconds:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"GpNetworkStartTimeoutPolicyValue=dword:0000003c"
http://support.microsoft.com/kb/2421599
The KB is talks about making GP application more stable but, wait for network I posted earlier in the thread already does that.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ” How to ask a question that is fixable.
-
Friday, February 15, 2013 4:51 PMThanks for the info. I doubt my sys admin will go for turning this policy on but, if someone can confirm this as a fix that would be awesome!
-
Friday, February 15, 2013 6:00 PM
The error comes up because MDT has some error handling logic. Do you really care of if there is a transient condition that is handled well but, does show up in the summary? If you only care about failures you could SkipFinalSummary=YES.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ” How to ask a question that is fixable.

