I have had this problem through all betas of MDT 2012 and it still exists in the final release.
Windows 7 Professional wSP1 x64 installed using all default settings.
Installing Symantec Endpoint Protection 12 R1
Connecting to any SAMBA computer (specifically Mac OSXS.
If I install the OS using MDT 2012 (there is no issue with MDT 2010) once I install SEP the computer can no longer connect to SAMBA computers. Specifically tested with Mac OSXS but also tested with CentOS. The OS can connect with no issues before installing but once SEP touches the computer (uninstalling SEP does not fix the problem) it can no longer connect to SAMBA machines. When attempting to connect I get "The specified server cannot perform the requested operation.".
I can not find anything in the documentation or changelog for 2012 that would lead to this issue. Also this is *NOT* a problem with SEP as there are zero issues with MDT 2010.
I have a similar issue. I've searched many forums and yours posting is the closest I've come to my issue, although it might not be exactly the same as up until a few days ago, I've been deploying images with MDT 2012 without problems, this only started happening a few days ago.
I have just deployed several WIM images from my MDT 2012 server. The images appear to install normally as I would expect, however when I come to use the computers that have been created I have several problems:
* I am unable to browse to a share on Buffalo Networked Attached Storage (NAS) device. After a long pause I receive the following error:
The specified server cannot perform the requested operation.
* I can browse to a share on a Windows Server 2008 file server or Windows 7 workstation.
* My installed image does not remember the credentials of the last logged on user, username/password must be retyped for each logon.
* My CachedLogonsCount is somehow reduced to 2 instead of the usual default of 10.
Currently I am troubleshooting various scenarios such as recreating my reference images, recreating my deployment share, etc. I will let you know the outcome.
Spent most of the morning on this but think I have found the answer.
New to MDT 2012 is a feature called "Apply Local GPO Pack". This feature is part of the SystemRestore section of the default Task Sequence.
Following deployment of a computer by MDT 2012, this step is run - and it modifies Security Options in the Local Security Policy. If these same settings are not configured or not defined in your Group Policy (in an AD environment) then the Local Security Policy wins.
Specifically there are some options regarding LM and NTLM that get changed and a setting for "Require Secure Communications Always". Both of these settings cause connections to SAMBA shares to be disabled - there are lots of settings that get changed, including the default cached credential count, which I mentioned.
To disable this from happening when you deploy your images in MDT 2012 you can go into the Task Sequence - right click Properties. Click on the Task Sequence tab and locate the "Apply Local GPO Package" item in the "SystemRestore" section.
Then, click on the Options tab and select "Disable this step".
Alternatively, add ApplyGPOPack=NO to your customsettings.ini
Full list of settings changed by this feature available here (see Excel attachment)
I don't understand why Microsoft decided to have this set by default in their task sequences. It makes more sense to deploy a default installation of Windows 7 and then have the option of enabling the additional security options.
I hope this helps with your issue or points you in the right direction.
Thank you for your insight, nyQuist! I hadn't even thought of the local policy being the cause of it.
I took an export of an older Windows 7 computer Local Policy, and one from the new image I created with MDT 2012 and compared them in Excel. With the settings that differed, I started changing them to the values that were set on the working machine, one by one, until I found the one that was causing the problems.
In my case, the one that caused problems was:
Microsoft network client: Digitally sign communications (always) Enabled
I had to set this to Disabled, then reboot the computer. Once I did that I was able to connect to Samba shares again. Can someone else test this setting in their environment and see if it helps?
- Proposed as answer by ITGuruNumber2 Thursday, January 17, 2013 8:48 PM