Aspergillus

Results: Bug Microsoft Support confirmed this to be a bug. Short description: if an application has two deployment types both using a global condition based on powershell and one those global conditions has the "run with logged on user credentials" checked. Deployment will fail. For if deployed to device collection.

Dear m8's, We got an Application deployed to a Usercolletion and to Devicecollection. As soon as we add any powershell-script based global condition to the requirements of the deploymenttype the application disappears from the Softwarecenter (Device-deployment) but it stays in the Softwarecatalog (User-deployment) If the Condition is Powershell and returns Stringit fails. if it is Powershell and returns boolean it works. if it is VBS and returns strin or boolean it works. For the Userdeployment it all works find the global condition script works as planed. But we can not deploy an application with such a global contition to devices. As an Example when we follow exactly this: http://www.kraftkennedy.com/creating-global-conditions-in-configuration-manager-2012/ We can not deploy an ap with that condition to a devicecollection only usercollection work. From the comments we see that others semm to have the same Problem. Any Ideas? Regards Aspi .... I can't believe it works as designed. Opened a supportcase at MS if we can not find a solution here i will report MS supportcase results here SystemCenter Configuration Manager 2012 SP2 CU4

Hi m8's. We experience a stange behaviour we do not understand. In Short. - If a User is Member of the Local Group Configmgr- Rempotecontrollusers he can do remotecontrol. - If the same user ist member of an AD-Group and this AD Group is member of the local Configmgr-RemoteuserGroup the User can not do remotecontroll. --------------------------- We have an Active Directory Group (Local Domain Permission Group) and this Group has the "Role Remote Tools operator" in Configmgr. If a User is made Member of this Group he can do remotcontroll only if he has Administrator rights. If we open local Groups now on our Domain Machines there is a Group called Configmgr-RemoteUsers andf in this Group we find our Group AD Group .... If i put the User in this local group directly it works without Admin Rights. if in this local group is only the AD Group in wich the User is.. it does not work. Is this working as designed? Regardas Rolf

It seems that we identified the problem with the help of Microsoft Support.. We fixed it with a workarround: Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\PPP\EAP\13 ValueName: NoRevocationCheck Type: REG_DWORD Value: 1 After that Win 8.1 and Win PE 5.0 where able to connect. Be aware it is a workarround and is bypassing some security.. so it should not be a permanent solution. Regards Aspi

We tried to get our wired 802.1x EAP-TLS working on a windows 8.1 Machine to export the profile there. We are not even able to manually configure Windows 8.1 to connect to our Network!!

Hi M8, Since Win PE 4.0 its part of the PE Distribution. In SCCM go to your Bootimage properties... Then open the tab "Optional Components" and ad Microsoft .NET (WinPE-Dot3Svc) This integrates the 802.1x Service into the Boot Image. You have then to activate it during the task Sequence by a package that does basically the following: REM Import personal/Machine Certificate certutil -p password -importPFX cert.pfx REM Importiere Root Zertifikat... certutil.exe -addstore root CETRIFICATE.cer Rem Start The Network Service and set it to automatic restart sc config Dot3svc start= auto net start Dot3svc REM Import Networkprofile that was exported from a running win7/8 system netsh lan add profile filename=NetProfile.xml This is how it used to work for usin PE 4.0 Microsoft states there are no changes in PE 5.0 but after upgdading our bootimages 802.1x does not work. Anyone here got an idea what might have changed? Regards Aspi