In the spirit of 'eating your own dog food' I often test new deployments on my team's client devices - to make this easier I've created a WQL, query-based collection of all of their client devices based upon Primary User's group membership. The nice thing about this group is that any new devices we're testing will automatically be added.
Select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client FROM SMS_R_System JOIN SMS_UserMachineRelationship ON SMS_R_System.Name=SMS_UserMachineRelationship.ResourceName JOIN SMS_R_User ON SMS_UserMachineRelationship.UniqueUserName=SMS_R_User.UniqueUserName WHERE SMS_UserMachineRelationship.Types=1 AND SMS_R_User.UserGroupName="DOMAIN\\GroupName" AND SMS_R_System.OperatingSystemNameandVersion like "Microsoft Windows NT Workstation%"
Issues with the Network Access Account following an SCCM 2012 R2 upgrade are not uncommon:
Despite creating a new account, deleting the old account and recreating boot images we were still running into issues on some refresh scenarios with Task Sequences failing with a 80070002 error code - bare-metal deployments of new machines were fine, using the same boot images.
It turns out that the clients targeted by the refresh Task Sequence we're still running the legacy, non-R2, SCCM client. After upgrading the client to the R2 version all Task Sequences ran without issue.
Ran into a strange issue today with two Citrix servers, both suddenly started to exhibit extremely long logins of ~3 minutes - this initially meant that users could not access any published applications on the servers due to the default LogoffCheckerStartupDelayInSeconds timeout of 60 seconds. Sessions would start, hang at the "Welcome" stage of the Citrix application startup and then the session would terminate after 60 seconds.
We modified this registry key to 180 seconds and applications would then launch, workaround in-place, but what was really causing the issue?
After a LOT of troubleshooting it was discovered that there were 100+ profile folders on the servers. We scripted cleanup of these profiles using the script below, login times dropped to ~25 seconds.
Ran into an issue with our applictaiobn catalog site this week - no changes had been made, no certificates renewed etc. Not sure what triggered it!
A revised version of a script I found here:
Use this script in an SCCM package that contains MSU fuiles to mass install updates. You can include as many MSU files as you like.