Update SCCM Collection Update Schedules

By default, SCCM collections update once a week. this may or may not be sufficient for your needs. When you create a new Collection in Powershell, you can pass a -RefreshSchedule parameter.
Set-CMUserCollection and Set-CMDeviceCollection accept the -RefreshSchedule parameter though this doesn't appear to be documented anywhere - Google suggests long scripts to do this.

We wanted to set our user collections to update every 4 hours. It proved to be quite simple. First we created a new schedule object

$sched= New-CMSchedule -recurinterval Hours -recurcount 4

 Then we passed it to each user collection.

foreach ($x in Get-CMUserCollection){Set-CMUserCollection -name $x.name -RefreshSchedule $sched}

Make Applications Run Without Administrator rights, despite prompts to elevate

This post will Attempt to consolidate everything I know about making applications under windows work as a user, once administrative rights have been revoked. This is based on my experience with windows 7, So YMMV for windows 8 and 10.

1. File and Folder Permissions. 

Users do not have rights to write to C:\Program Files or C:\Program Files(x86) Folders. Many applications will have a local database or logfile stored with the application. Typically you get a permission Denied, or cant write to file error, rather then a UAC prompt.

In this case, Permission the Applications Folder so the pcname\Users group has modify rights. The Permissions should propagate, down to files and subfolders, and this will clear up your issues. if you have many installs of an application, you can deploy a script to Change the permissions.

We simply use a bat file that calls ICACLS. This gets deployed Via SCCM to the System

 ICACLS <folder Path> /grant <group>:(OI)(CI)M  

The options at the end Specify 
(OI) - object inherit
(CI) - container inherit
M- Modify

So the command ends up looking like:

 ICACLS "C:\Program Files (x86)\PFC6000" /grant Users:(OI)(CI)M  

Full ICACLS documentation can be found on technet. Always use the local group - frequent calls to AD for application permissions can slow the system down.

2. AppCompatFlags

Some Applications can be flagged in the registry to run in compatibility mode. You can use AppCompat Flags to specify an application to run in XP mode, and require admin access. Just because an application prompts for admin, doesnt mean it Requires it.

 HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers  

Simply deleting the key can cause the application to work. I have also seen this key below used, though much less commonly.

 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers  

3. Manifest Files 

EXE's can use a manifest file to require an application to run as admin. The manifest file will be found with the EXE, and will be the name of the exe with the .manifest extension. So notepad.exe would have notepad.exe.manifest.

and example manifest file is shown below:

 <?xml version="1.0" encoding="utf-8" standalone="yes"?>  
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">  
  <assemblyIdentity version="1.0.0.0"  
     processorArchitecture="X86"  
     name="Myobp.exe"  
     type="win32" />  
  <description>Manifest for Premier</description>  
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">  
   <security>  
    <requestedPrivileges>  
      <requestedExecutionLevel  
         level="RUNASADMIN"  
         uiAccess="false"/>  
     </requestedPrivileges>  
   </security>  
  </trustInfo>  
 </assembly>  

I have had luck simply deleting the file, though manifest files can also point to older versions of DLL's. In that case,  You may have better luck replacing RUNASADMIN with ASINVOKER

4.Invoke Installer

The UAC can be prompted if it thinks you are about to run an installer. You may or may not be running one, but if the following conditions apply, you will get prompted.
(From: http://msdn.microsoft.com/en-us/library/aa905330.aspx)

Installer Detection only applies to:

• 32 bit executables
• Applications without a requestedExecutionLevel
• Interactive processes running as a Standard User with UAC enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords such as "install," "setup," and "update."
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side application manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the resource file data linked in the executable.
• Targeted sequences of bytes within the executable.
• Note: The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.

You can turn off Installer Detection by modifying the EnableInstallerDetection Registry Key

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System  

and setting the value form 1 to 0.

 This Can also be done Via GPO enterprise wide. The UAC Policies can be found in Computer Settings\Policies\Window Settings\Security Settings\Local Policies\Security Options

The User Account Control: Detect application installations and prompt for elevation policy setting controls the behavior of application installation detection for the computer.
The options are:

• Enabled. (Default for home) When an application installation package is detected that requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
• Disabled. (Default for enterprise) Application installation packages are not detected and prompted for elevation. Enterprises that are running standard user desktops and use delegated installation technologies such as Group Policy Software Installation or Systems Management Server (SMS) should disable this policy setting. In this case, installer detection is unnecessary.

5. Application Compatibility Tool Kit.

Pending - Please see TechRepublic Article @ http://www.techrepublic.com/blog/windows-and-office/selectively-disable-uac-for-your-trusted-vista-applications/

Try out time - SCCM 2016

Todays the day I build the SCCM 2016 Virtual Lab.

The Plan:

 VM1: AD/DNS/
VM2: SQL 2014
VM3: SCCM 2016

Lets see how this goes.

PXE Boot to run task sequence from shared NIC

Microsoft  offered this post on Reusing the same NIC for multiple PXE initiated deployments in System Center Configuration Manger OSD

http://blogs.technet.com/b/configurationmgr/archive/2015/08/27/reusing-the-same-nic-for-multiple-pxe-initiated-deployments-in-system-center-configuration-manger-osd.aspx

mac evolution

Found this background image:

AD and SCCM Device Cleanup

This Script Removes devices from AD and SCCM that have not been logged onto in 90days, and have not reset thier device password in 120. It then goes on to check the User device affinity to ensure Devices are sorted to the same OU as the Primary owner. (Unless that user is a member of the service desk, then leave as is. it Also maintains a complete log of all changes.

$log="C:\temp\sorter.log
$date=get-date
$oulist=Get-ADOrganizationalUnit -LDAPFilter '(name=*)' -SearchBase 'OU=DEPT,DC=Domain,DC=com' -SearchScope OneLevel #get-oulist

########################################Cleanup Stale PC's##################

$t="Starting Purge on $date"
$t|out-file $log -append


#Collect Stale devices.
Foreach ($x in Get-QADComputer -NotLoggedOnFor 90 -PasswordNotChangedFor 120 -searchroot Domain.com/Dept/){
$t="$x.name was Purged on $date"
$t|out-file $log -append 
Write-host $t
#Remove from AD/SCCM
remove-cmdevice -devicename $x.name –force –confirm:$false  
remove-qadobject $x.DN –force –confirm:$false
 
}

$t="Purge complete on $date. "
$t|out-file $log -append

############################################## Object Sorter

$t="Starting Sort on $date"
$t|out-file $log -append

#get all computers
foreach ($z in Get-qadcomputer -searchroot "Domain.com/Dept/"){
$t=""
$x=get-cmdevice -name $z.name 
if (!$x.username){ #check for Assigned user. If none log, and move on.
$t=$z.dn+" no user attached - unable to move."
write-host $t
$t|out-file $log -append

}elseif((Get-ADUser $x.Username -Properties memberof).memberof -like "CN=ISM-ALL*"){ #if member of servicedesk, dont touch 

$t=$z.dn+" last used by service desk. Do not move.."
write-host $t
$t|out-file $log -append

}else{
$y=get-qaduser $x.UserName;

$f=$z.name.lenght+16
$G=$y.displayname.length+14
$zdn= $z.dn.substring($f)
$ydn= $y.dn.substring($g)
#write-host $f $zdn 
if($zDN -match $ydn){ #if user dn and PC dn match - move on.
 write-host $z.name " is properly located"
 $zdn=""
 $ydn=""
}else{
 $zdn=""
 $ydn=""
#sort based on DN.

Foreach ($q in $OUlist){
$q.Name
if ($y.DN -match $q.name){write-host "yes";$dept=$q.name}
}

$newou="Domain.com/Dept/"+ $dept +"/Computers"
$t=$z.dn+" moved to "+$newou
write-host $t
$t|out-file $log -append
Move-QADObject $z.dn -NewParentContainer $NewOU
$NewOU=""
}#end move if
}#end no user if
}#end dn match if

Adding Users Devices to a Collection by First and Last Name

Recently I was given a Set of User's Names to exclude from a deployment. Easy. Until I realized the deployment was deployed to devices, not users. I dropped the user list into a text file. First Last, each on its own line. I read the file and grabbed the username, then performed a User Device affinity check, throwing the associated computer into the exclusion collection.

$collectionname="Exclude Reader DC"

foreach ($x in gc C:\temp\adobe.txt){
$y=get-qaduser $x
$user="DOMAIN\"+$y.samaccountname
$z=Get-CMUserDeviceAffinity -UserName $user
#$q=Get-CMDevice -ResourceId $z.resourceid
#$q.name
$z.resourceid 
 Add-CMDeviceCollectionDirectMembershipRule -CollectionName $collectionname -ResourceId $z.resourceid   
}