Further to my previous post here I can confirm that version 2.6 of the Excel and Word apps that were released on 9th October have resolved the crashing issue. Yes I know literally a day after blogging it and I have only just sent out this update! No rest for the wicked hey.
Stay tuned for some bettter quality "non-bug-reporting" blog posts - I promise!
Tips and how to's from the cloudy world of Intune and other Microsoft Endpoint Manager technologies
Friday, 20 October 2017
Sunday, 8 October 2017
Intune iOS Office Apps crashing
It would appear that version 2.5 of the office apps for iOS are having issues launching when deployed with a MAM policy. The app launches and if it fails to fully load within 20 seconds it simply closes again. This is more prevalent in older devices. I have tested and confirmed this with the Word, Excel and OneDrive apps.
Tech support have confirmed that Apple are aware of the issue and is a default timeout within the code which cannot be amended. Expect an update to be released within the App Store within the next few weeks.
Tech support have confirmed that Apple are aware of the issue and is a default timeout within the code which cannot be amended. Expect an update to be released within the App Store within the next few weeks.
Sunday, 17 September 2017
Android for Work play store crashing bug - resolved
As per my previous blog post here there was a bug where Android for Work devices experienced an issue in that the managed play store was frequently crashing during enrolment. This has now been resolved and the issue was due to a timeout between Intune and the managed Google play app on enrolment. Microsoft and Google worked together to resolve this but unfortunately I have not been able to get any more information. I can confirm now though that I have removed the workaround and we are deploying all apps to the user on initial enrolment which seems to be working as expected.
Tuesday, 12 September 2017
Android for Work Exchange conditional access bug - resolved
I can confirm that as per my previous post here the Exchange conditional access issue was only affecting 1st wave builds of SCCM 1706 and the update released on 31st August includes the fix required to resolve this issue.
Tuesday, 5 September 2017
SCCM 1706 (1st Wave) Update 2 Console updates
If you were one of the eager beavers like me to run a script in order to be able to access the first wave of the 1706 update you may have notice the recent release of this update https://support.microsoft.com/en-us/help/4036267/update-2-for-system-center-configuration-manager-version-1706-first-wa
Just thought I would share my findings as when I was trying to update the SCCM console I noticed that there were two updates - 5.00.8540.1600 and 5.00.8540.1601 the former being related to the release of update 1, which was only applicable at the time for systems updated between 8th and 11th August 2017 inclusive, which our was not.
I had forgotten that in the past that for multiple updates of the console there was a specific process that has to be followed in order for all of the updates to install successfully in that the console needed to be re-launched between each update. With this particular update I found that if this process was not followed the below error was displayed
Just thought I would share my findings as when I was trying to update the SCCM console I noticed that there were two updates - 5.00.8540.1600 and 5.00.8540.1601 the former being related to the release of update 1, which was only applicable at the time for systems updated between 8th and 11th August 2017 inclusive, which our was not.
I had forgotten that in the past that for multiple updates of the console there was a specific process that has to be followed in order for all of the updates to install successfully in that the console needed to be re-launched between each update. With this particular update I found that if this process was not followed the below error was displayed
And when viewing the report found that it contained the entry "AdminUI.ExtensionInstaller.exe
Error: 0 : System.IO.IOException\r\nThe process cannot access the file
'C:\Program Files
(x86)\ConfigMgr10\AdminconsoleSetup\469A3000-14DA-425E-B288-4B0E16DB87C4'
because it is being used by another process.\r\n"
The re launch of the console followed by attempting the second update again would not work this time and the only resolution I could find for this was to restart the system. I therefore, in order to prevent this reboot, carried out the following process
Launched the console for the first time and proceeded with the update
Launched the console for the second time, however this time selected "Cancel" and let the console load before closing
I then launched the console for a third time and proceeded with the second console update
Thursday, 31 August 2017
Intune hybrid portal migration to Azure
Our Intune environment is in a hybrid configuration however I wanted to have a look around the layout of the Intune portal in Azure. This was prompted by the various emails I received from Microsoft stating that there are only a few accounts to be migrated, therefore I reviewed the potential migration blockers here https://blogs.technet.microsoft.com/intunesupport/2017/05/17/intune-migration-blockers-for-grouping-targeting/
It turns out that hybrid Intune is not yet supported for the Azure portal - this is not clearly documented anywhere as far as I am aware (I have also confirmed this with Microsoft technical support).
Granted there are very few reasons in which you would need to access the portal in this configuration but it would be good to have one less interface to have to log in to...
I have found a user voice there here where this feature can be voted up, looks like work has been started on this as of 14/8/17 https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/8466106-no-option-to-enter-a-wifi-password-when-creating-a
So to help with my studies, trial subscription it is for now then.
It turns out that hybrid Intune is not yet supported for the Azure portal - this is not clearly documented anywhere as far as I am aware (I have also confirmed this with Microsoft technical support).
Granted there are very few reasons in which you would need to access the portal in this configuration but it would be good to have one less interface to have to log in to...
I have found a user voice there here where this feature can be voted up, looks like work has been started on this as of 14/8/17 https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/8466106-no-option-to-enter-a-wifi-password-when-creating-a
So to help with my studies, trial subscription it is for now then.
Subscribe to:
Posts (Atom)