1

Closed

[2.0] The function of "Retain network folder settings" failed in OSD of SCCM 2007

description

Hello, I met a problem when use the "Retain network folder settings" check-box in OSD.
 
The following steps can reproduce this issue:
  1. Created a custom Task Sequence in OSD of SCCM 2007.
  2. Right-click the created Task Sequence, and click "Edit" in menu.
  3. Added a OEM Deployment Pack.
  4. Under the "Logs / Return Files" page, filled in the "Path", "Account", and "Password" text-box,
    and selected "Map a drive letter" check-box, and assigned a drive, e.g. "Z:".
  5. Clicked "Apply" button.
  6. Added a OEM Deployment Pack again.
  7. Under the "Logs / Return Files" page, selected the "Retain network folder settings" check-box,
    the "Path", "Account", and "Password" text-box would be filled automatically, and
    "Map a drive letter" check-box also would be selected automatically. (1.jpg)
  8. Clicked "Apply" button, that failed and poped-up the error dialog box. (2.jpg)
  9. Canceled the "Retain network folder settings" check-box, and clicked "Apply" button, also to
    failed and poped-up the error dialog box. (3.jpg).
     
    But when I canceled the "Retain network folder settings" check-box, and re-inputed Password by
    manual, and clicked "Apply" button, that successed! And re-selected "Retain network folder
    settings" check-box, and clicked "Apply" button, also to Successed!
     
    Why?
     
    Otherwise, I noted the "Map a drive" check-box would be checked and disabled automatically if
    the "Retain network folder settings" had been checked. That means the pre-OEM Pack must use
    the Mapping drive, otherwise the "Retain network folder settings" function of current OEM Pack
    is invalid. But I thought which condition is rigid and strange. Because the "Map a drive" function
    is a optional, no a required.

file attachments

Closed Dec 18, 2009 at 12:01 AM by rhearn

comments

rhearn wrote May 14, 2009 at 8:41 PM

I have not seen this error before and cannot reproduce it using your steps.
Please send the SmsAdminUI.log file, located in the AdminUI\AdminUILog directory. It should note exactly what the error was that occurred.

In my test, I did see an error occur, but the error was that it was failing to save the password property into WMI. I am investigating that issue right now.

aeolus008 wrote May 18, 2009 at 4:13 AM

rhearn, I think we met the same problem. My test environment is win2008. And I used above steps to reproduced this issue in win2003. (Win2003.jpg)

wrote May 18, 2009 at 4:13 AM

aeolus008 wrote May 21, 2009 at 8:58 AM

Hi rhearn,

I found another problem about failing to save the password. I am not sure whether the cause is
or not same with failing of save the password property into WMI.

The following steps can reproduce this issue:
  1. Created a custom TS.
  2. Added a OEM Deployment Pack, and named "1 Action".
  3. Edited "2 Action", and under Logs/Return Files page, filled in "Path", "Account", "Password",
    "Mapping drive", and my Password is "admin" in this case.
  4. Click "Apply". ( 1_Action.jpg)
  5. Added a OEM Deployment Pack again, and named "2 Action".
  6. Edited "2 Action", and under Logs/Return Files page, we known that will pop-up error dialog
    box if we checked "Retain" check-box and click "Apply". So I found the 7th step to avoid this status.
  7. Checked "Retain" check-box but no click "Apply", the "Path", "Account", "Password", "Mapping drive"
    has been filled automatically. Then unchecked "Retain" check-box. and changed the Password from
    "admin" to "test", click "Apply"(2_Action_a.jpg). Return to Logs/Return Files page, and checked "Retain"
    check-box again, and click "Apply" (2_Action_b.jpg). Success!
  8. Advertised this TS to client and ran. The "1 Action" is success, but the "2 Action" is fail.
I checked the log file and found "MapNetworkDrive: Password: test" not "admin"! So amazing!

wrote May 21, 2009 at 8:58 AM

rhearn wrote Jun 3, 2009 at 12:31 AM

I have successfully reproduced this issue and discovered the cause.

The issue is that the underlying action of storing and retrieving passwords ("secret" properties) in a task sequence does not function. SCCM encrypts secret properties as they are being saved and handles the unencryption on the fly as needed during a task sequence. The process does not work, however, when trying to copy a password from one saved secret property to another. Either (a) the process fails because SCCM cannot correctly save the value, or (b) the process retrieves a garbage value which is then saved as "encrypted garbage". Which one happens depends on how you access and copy the property.

I am currently investigating alternative methods for accomplishing this, but in the meantime this functionality is broken. I will check in code to disable the password copy functionality until a fix can be found (if at all) or a workaround can be considered.

wrote Jun 16, 2009 at 10:58 PM

Associated with changeset 25531.

rhearn wrote Aug 27, 2009 at 7:39 PM

Added to SCIF 2.0 planned changes.

aeolus008 wrote Nov 26, 2009 at 8:04 AM

Hello rhearn, How about this problem? Or where can I get the fixed code that about disable the password copy functionality? Thanks.

wrote Dec 18, 2009 at 12:01 AM

Resolved with changeset 41450.

wrote Feb 13, 2013 at 11:45 PM

wrote May 16, 2013 at 6:21 AM