syswow64 blog

Creating Global Conditions in System Center configuration Manager for Office 365 deployments Firstly I would recommend reading the Microsoft docs article below. https://docs.microsoft.com/en-us/sccm/apps/deploy-use/create-global-conditions Software Library  >  Application Management  >  Global Conditions . Scenario: I have an AD group " SD-LSG-Comp-Microsoft Project ClickToRun"  with computer objects that should install Office 365 -  ProjectProXVolume edition. I wanted to create one application with multiple deployment types depending on their AD membership. For example if the computer is only a members of the  " SD-LSG-Comp-Microsoft Project ClickToRun" AD group then the deployment should only run the deployment Type " Office 365 Default Deployment Type-Install_InstallProject.cmd ".   This deplyoment Type calls the Office 365 setup.exe with a configuration xml detailing the  <Product ID="ProjectProXVolume">. (For a detailed understa

Scenario: I wanted to package the Office 365 Activation Troubleshooter ( Officeact.diagcab ) for Office 365 users with activation issues. I needed to find out the commands to use as well as the appropriate Detection Method. 1. Download: Officeact.diagcab https://aka.ms/diag_officeact 2. Create a PowerShell (Diagnostics.Office365.ps1) script to call the officeact.diagcab file. See example below 3. Create an SCCM Script application calling the Diagnostics.Office365.ps1 script powershell -ExecutionPolicy Bypass .\Diagnostics.Office365.ps1 Select the Detection Method tab and select radial next to "Use a custom script to detect the presence of the this deployment type". Select the Edit option on the right and set the script type to PowerShell and the script content as appropriate to the application. The script below will look at all running processes and filter out all processes that equal msdt; if a process matching this string is found the client will return an exit code of 0

What Are Server Groups? Within SCCM Assets and Compliance you can create a collection containing Server Client membership. Once the 'Server Group' feature is enabled the properties of the collection will contain an additional option to declare that all members of the collection are part of a server group.   This means SCCM knows that the servers within this collection must be treated with specific logic and settings. In the example below the collection contains three nodes of a cluster and only one node may be Software Updated at a time. Once policy is received for the Software Update Group deployment an election is held in which one of the nodes will engage a lock state forcing the other nodes to wait until it has been released. The UpdatesDeployment.log details the 'Lock State'. Once the node has taken the lock (Lock State: 1) the server will then run the 'Node Drain Script' and continue if the script has an exit code of 0 zero or if the script times out (600

Scenario: A two node cluster required new and old software updates to bring it up to compliance. The installation of KB3000850 was failing to install either manually or via SCCM deployment on one node  but not the other. WUAHandler.log Installation job encountered some failures. Error = 0x80240022. Commit Result = 0x00000001 CBS.log  Not able to add file to extract: update.ses [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND] CBS    Store corruption, manifest missing for package: Package_33_for_KB3081320~31bf3856ad364e35~amd64~~6.3.1.1 CBS    Mark store corruption flag because of package: Package_33_for_KB3081320~31bf3856ad364e35~amd64~~6.3.1.1. [HRESULT = 0x800f0831 - CBS_E_STORE_CORRUPTION]  Failed to resolve package [HRESULT = 0x800f0831 - CBS_E_STORE_CORRUPTION] WER: Generating failure report for package: Package_for_KB3000850~31bf3856ad364e35~amd64~~6.3.1.8, status: 0x800f0831, failure source: Execute, start state: Staged, target state: Installed, client id: WindowsUpdateAgent Common

Scenario: The client has pretty standard ConfigMgr setup to manage there primary and dev systems. The clients communicate to Distribution and Management Points however, the PORT 8530 from the Software update Point ( SRVSUP01 ) can not be opened to clients in the dev vlan. Without getting into the technical architecture of the configured firewall rules a second Software update Point would be required to over come this architectural design. However, the Dev client would not switch over to the new SUP ( SRVSUP02) . Upon opening a Browser window from a Dev client it was possible to navigate to the addresses below thus confirming the availability of the new SUP. http:// SRVSUP02 .Contoso.local :8530/SimpleAuthWebService/SimpleAuth.asmx   http:// SRVSUP02 .Contoso.local :8530/ClientWebService/wusserverversion.xml   http:// SRVSUP02 .Contoso.local :8530/Selfupdate/wuident.cab The WUAHandler.log was reporting a scan failure error code: 0x8024401c. Implying the Scan agent was not able to connec