Friday, March 24, 2017

Office 365 Update Restarts my Apps in SCCM

Office 365 Update Restarts my Apps in SCCM

Pushing Office 365 C2R updates through SCCM 1610 causes Office applications to close unexpectedly on client PCs

This is a known bug since the release of ConfigMgr CB 1610. and was resolved with Hotfix KB4010155

https://support.microsoft.com/en-us/help/4010155/update-rollup-for-system-center-configuration-manager-current-branch-v 
  • After you start installation of Office updates from Software Center, users do not receive a notification message to exit all open Office 365 applications. This behavior occurs even with the forceappshutdown=False switch in the Configuration.xml file for Office 365.
Conclusion
Install all hotfixes
https://support.microsoft.com/help/4010155
https://support.microsoft.com/help/4016483

Wednesday, March 22, 2017

Dell E5450 Bricked after applying CCTK.exe command

Dell E5450 Bricked after applying CCTK.exe command

Dell E5450 with i3 Processors a CCTK.exe warning

We recently had our E5450 Latitude failing to post following a stand SCCM Window Task Sequence.  It was collected for diagnosis and motherboard swap out.  While no diagnosis was performed (pointless sending away) we was returned within a few days with a new motherboard.

Upon receiving it I cautiously rebuilt it with success with a cut down version of the task sequence; I have simply installed the Windows Image (WIM) and driver package.  Upon introducing additional steps to the SCCM task sequence I see a complete failure of the BIOS as previously experienced.

The failed post was the result of CCTK.EXE modifying BIOS settings.

We are using the latest version of CCTK 3.2 with the following commands; 

cctk --secureboot=enable --valsetuppwd=PASSWORD
cctk --wakeonlan=enable --valsetuppwd=PASSWORD
cctk --uefinwstack=enable --valsetuppwd=PASSWORD
cctk --embsataraid=ahci --valsetuppwd=PASSWORD
cctk --tpm=on --valsetuppwd=PASSWORD
cctk --tpmactivation=activate --valsetuppwd=PASSWORD
cctk --virtualization=enable --valsetuppwd=PASSWORD
cctk --vtfordirectio=on --valsetuppwd=PASSWORD
cctk --trustexecution=on --valsetuppwd=PASSWORD
cctk --autoon=disable --valsetuppwd=PASSWORD 

After analysis and discussion with Dell product groups they found that CCTK is forcefully arming TrustExecution in a way that conflicts the chain of trust. The basis of this is because the i3 CPUs within that unit model do not fully support Trust Execution which has been causing the NO POST via the CPU failure.

When this happens its driving the first measurement of the CPU to validate the signed module which isn’t supported (PCR 0 which holds the Core Root of Trust Measurement (CRTM). The issue was not replicated on any i5 or i7 systems we have in our lab.

Moving Forward; Dell recommend any units in a failed state have the motherboard replaced and to remove TrustExecution Command from your CCTK.ini 

Monday, March 20, 2017

Sharepoint documents will not open in Word/Excel

Sharepoint documents will not open in Word/Excel

Today I have been dealing with a very interesting Office 365 / SharePoint issue. It was reported that the Edit in Application button within SharePoint i.e. “Edit in Excel” “Edit in Word” is not working correctly and results in an empty Spreadsheet or empty Word document.

Viewing and Editing within the browser is fully functional and the behaviour varies depending on computers within specific OU in active directory.  It is worth noting at this point the estate consisted of Office 2013 ProPlus installations running on Windows 8.1.

The fact that identical systems with identical software versions patch to the same level, resulted in different behaviour could only mean Group Policy was different between them.



I was quickly able to find the offending policy; "Block signing into Office: Enabled". The screen shot above details a systems policy with the issue.


With the Standard Workstation GPO's the policy "Block signing into Office: Enabled" is not configured and Office applications can see the Sign-In option and can login to Office 365. 

Upon logging into a domain joined system Microsoft Office will login by default with the same account used to login to the computer.  If the account used to login to the computer ( i.e. SA_U1234567) is different from the account used to login to Office 365  (i.e. U1234567) the application Excel will fail to authenticate.  The Application will attempt to open the SharePoint URL intended for U1234567 and authenticate site/file; it will attempt to authenticate against the locally log on user ( i.e. SA_U1234567) who does not have permission and fail. 

For example the SA_U1234567 will need to have permissions to the resource U1234567 has selected within the Office 365 portal to "Edit in Excel". If the account SA_U1234567 does not have rights Excel will present, the user with the following Information message.  "Sorry, we couldn't open HTTPS://...SharePoint.com/Sites/…../Document.XLS"




It will follow up with a Warning message explaining:
Microsoft Excel cannot access the file 'HTTPS://...SharePoint.com/Sites/…../Document.XLS".  There are several possible reasons:

The message clearly explains that excel cannot access the file. Without an authenticated account the file will not be accessible; the first “possible reasons”, “The File name or path does not exist” is true from the perspective that Excel cannot find the file request.


If the account used to login to the computer is U1234567 and Office 365 /SharePoint is authenticated with the account U1234567 then the “Edit in Excel” will pass the MS-Excel Protocol a site URL that can be authenticated; resulting in success.

The Workstation that was unable to “Edit in Excel”  was applying the policy "Block signing into Office : Enabled". This configuration blocks the ability for the Microsoft Application to Sign-in; Excel was not able even attempting to authenticate against Office 365. 

Within Office 365/SharePoint when the button is clicked to "Edit in Excel" essentially the user is  initiating a hyperlink calling the protocol MS-Excel with the full URL to the resource.

ms-excel:ofv|u|https://....sharepoint.com/sites/......EXCELFILE.xlsx




In the case of the Workstation that was unable to “Edit in Excel” the protocol for ms-excel opens Excel (set through File Association) and the URL is ignored. As the Sign-In is block Excel does not even attempt to find the SharePoint site and the user simply see a blank Excel spreadsheet.  It is unfortunate that the User does not get a dialogue box explaining the Sign-In is block and is left to believe the operating failed. 

Conclusion
It is worth noting that If you are seeing the Information and Warning dialogue boxes your issue will most likely relate to Authentication and access to the resource.  If you are presented with an empty Excel or Word document then Policy is a root of investigation.