[mssms] RE: 1709 Issues

2018-01-19 Thread ODONNELL Aaron M
We've seen both those two issues in our 1709 testing as well, and both those 
fixes worked for us in most cases. A few computers are still having the outlook 
search issue even after a repair + cleaning up the OSTs and creating a new 
Outlook profile. We haven't gotten very far in pursuing it since 1709 is still 
in testing and we are still working through a host of 1703 upgrade issues that 
have a much bigger priority.


Thanks,

Aaron O'Donnell

From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On 
Behalf Of Enley, Carl
Sent: Friday, January 19, 2018 5:53 AM
To: mssms@lists.myitforum.com
Subject: [mssms] 1709 Issues

We are currently starting to pilot the 1709 update to our users and have 
started to notice a few issues, I am curious if anyone else is seeing the same 
problems we are.

We are using 1709 Enterprise and SCCM 1706 task sequence to deploy, we have 
Office 2016 .msi version installed.

1 - After upgrading to 1709 our users are having search issues with Outlook 
2016, very similar to the issues last June when the security patch broke the 
search function. Basically when they search they have a message saying 
"Something went wrong and your search couldn't be completed", results are 
retuned but they appear to be missing some items. I was able to fix the issue 
by deleting the users .OST file and performing an Office repair, neither one by 
itself would fix the issue. This is really not a great solution as our users 
have pretty large .OST files and some of them are connected via slow WAN links.

Seems I may not be alone -
https://social.technet.microsoft.com/Forums/ie/en-US/c9673cdc-0fa9-4126-9acc-b9ec4ae3/after-windows-10-fall-update-1709-outlook-search-error?forum=outlook

2 - After upgrading to 1709 when a user is in Excel 2016 and they use the File 
> Share > Email to send the workbook via email they receive the following error 
"  General mail failure. Quit Excel, restart the mail system and try again". 
The only way to fic this is to delete the MAPI32.DLL file from C:\Program Files 
(x86)\Common Files\system\MSMAPI\1033\ directory.

Again it doesn't look like I am alone -
https://social.technet.microsoft.com/Forums/office/en-US/4ca08c76-5252-40a2-88bb-dd430d637c2b/general-mail-failure-quit-microsoft-excel-restart-the-mail-system-and-try-again?forum=Office2016ITPro

https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/creator-update-excel-2016-general-mail-failure/07c820b6-3f5c-4a2d-bc2c-a051ec1effbf?auth=1

3 - My last issue is more of a product issue / feature request. While 
performing the 1709 upgrade over a VPN when the first reboot occurs the client 
loses contact with the MGT point, the task sequence continues to run and 
because I have the content downloaded before running the install succeeds and 
life is good. The problem with this is that the client does not queue up the 
status messages to be sent upon next connection to the network so our reporting 
is not reliable, we have no idea if the user is up to date via the monitoring 
tab...it gets messy as the systems stay in the "In progress" state.

I guess in an ideal world every user would be in an office somewhere connected 
to the corporate LAN while performing the feature updates but that is just not 
feasible in our environment as we have many road warriors and sales folks. I 
suppose some type of cloud / DMZ / IBCM type solution would help the situation 
but ideally I would expect the status messages to remain client side until the 
next time it connects to the MGT point and then send them up. Does anyone know 
of a script or something that could be run to re-send the task sequence status 
messages?

*Rant on/ - I have premiere support so I opened a ticket regarding the issues I 
am having, still waiting on response from MS but what I find ridiculous is that 
I have to open up 3 different tickets. So rather than working with one support 
rep I now have to mage 3 different support reps wanting to setup time to 
trouble shoot etc...all of the issues were caused by a simple 1709 feature 
update,  there should be someone who can take the lead and get the right people 
in the loop to help, why should I have to open and manage 3 different support 
cases because they broke core functionality in the product with the upgrade. I 
guess I understand the VPN status message thing should be a separate ticket but 
come on Office is Office and whether it is Outlook or Excel you would think the 
same guy could help me. *Rant off/






[mssms] Re: 1709 Issues

2018-01-19 Thread RJ Subscriber
Carl,


I'd contact my Microsoft TAM to help get the tickets consolidated under one 
support tech.  Let us know how your issues get resolved.  We're still using 
Office 2013 x86 and haven't seen those issues but Office 2016 will probably 
happen this year.


Good luck,

Russell



From: listsad...@lists.myitforum.com  on behalf 
of Enley, Carl 
Sent: Friday, January 19, 2018 5:52 AM
To: mssms@lists.myitforum.com
Subject: [mssms] 1709 Issues


We are currently starting to pilot the 1709 update to our users and have 
started to notice a few issues, I am curious if anyone else is seeing the same 
problems we are.



We are using 1709 Enterprise and SCCM 1706 task sequence to deploy, we have 
Office 2016 .msi version installed.



1 – After upgrading to 1709 our users are having search issues with Outlook 
2016, very similar to the issues last June when the security patch broke the 
search function. Basically when they search they have a message saying 
“Something went wrong and your search couldn’t be completed”, results are 
retuned but they appear to be missing some items. I was able to fix the issue 
by deleting the users .OST file and performing an Office repair, neither one by 
itself would fix the issue. This is really not a great solution as our users 
have pretty large .OST files and some of them are connected via slow WAN links.



Seems I may not be alone –

https://social.technet.microsoft.com/Forums/ie/en-US/c9673cdc-0fa9-4126-9acc-b9ec4ae3/after-windows-10-fall-update-1709-outlook-search-error?forum=outlook



2 – After upgrading to 1709 when a user is in Excel 2016 and they use the File 
> Share > Email to send the workbook via email they receive the following error 
“  General mail failure. Quit Excel, restart the mail system and try again”. 
The only way to fic this is to delete the MAPI32.DLL file from C:\Program Files 
(x86)\Common Files\system\MSMAPI\1033\ directory.



Again it doesn’t look like I am alone –

https://social.technet.microsoft.com/Forums/office/en-US/4ca08c76-5252-40a2-88bb-dd430d637c2b/general-mail-failure-quit-microsoft-excel-restart-the-mail-system-and-try-again?forum=Office2016ITPro

General mail failure. Quit Microsoft Excel, restart the 
...
social.technet.microsoft.com
This site uses cookies for analytics, personalized content and ads. By 
continuing to browse this site, you agree to this use. Learn more





https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/creator-update-excel-2016-general-mail-failure/07c820b6-3f5c-4a2d-bc2c-a051ec1effbf?auth=1

[http://answers.microsoft.com/static/images/icon_fb_answers3.png]

Creator update - Excel 2016 general mail failure 
...
answers.microsoft.com
Just seeing if anyone else has come across this issue: I've now updated 4 
laptops from 1703 to the 1709 creator update (Windows 10 Pro x64). Since the 
update, using ...





3 – My last issue is more of a product issue / feature request. While 
performing the 1709 upgrade over a VPN when the first reboot occurs the client 
loses contact with the MGT point, the task sequence continues to run and 
because I have the content downloaded before running the install succeeds and 
life is good. The problem with this is that the client does not queue up the 
status messages to be sent upon next connection to the network so our reporting 
is not reliable, we have no idea if the user is up to date via the monitoring 
tab…it gets messy as the systems stay in the “In progress” state.



I guess in an ideal world every user would be in an office somewhere connected 
to the corporate LAN while performing the feature updates but that is just not 
feasible in our environment as we have many road warriors and sales folks. I 
suppose some type of cloud / DMZ / IBCM type solution would help the situation 
but ideally I would expect the status messages to remain client side until the 
next time it connects to the MGT point and then send them up. Does anyone know 
of a script or something that could be run to re-send the task sequence status 
messages?



*Rant on/ - I have premiere support so I opened a ticket regarding the issues I 
am having, still waiting on response from MS but what I find ridiculous is that 
I have to open up 3 different tickets. So rather than working with one support 
rep I now have to mage 3 different support reps wanting to setup time to 

Re: [External] [mssms] RE: Office 365 updates basically impossible to deploy with Configmgr

2018-01-19 Thread Miller, Todd
I’m not having trouble getting the O365 patches to appear on my clients.  My 
trouble is the unacceptable user experience of how they are applied.  There 
should be no circumstance where ConfigMgr allows an O365 update to close all 
Office applications without any messaging.  The 1706 ConfigMgr agent will do 
just that when applying O365 updates on any client where the deadline for the 
O365 update is in the past.  This would happen any time that you turn on a 
computer that was not on for the 48 hours preceding the patch deadline.

I have professors that take laptops they use a couple of times a week to go 
give a lecture on Friday and PowerPoint just closes in the middle of the 
lecture because the deadline for the O365 patch was on Thursday and they missed 
the short notification window since they last used the laptop the previous 
Monday,

I have 1/3 of our computers that are hot seat shared machines.  The office 
notification becomes like a hot potato.  All the users ahead of the update 
postpone the notice because they don’t want to be interrupted in their work on 
the computer.  Then whoever happens to be at the computer when the deadline 
passes gets the update without warning and office apps are closed right out 
from under them.

The O365 update process as designed in ConfigMgr currently is only acceptable 
in situations where there is a one to one relationship between computer and 
user, and that computer is in use every day.   Otherwise the user of the 
computer at the time the update applies will just have the rug pulled out from 
under them.

I am working with premier on this issue, and so far we have found it is working 
as designed and they calling it a product flaw -so trying to figure out what to 
do,

I am  leaning towards abandoning O365 and switching to 2016 MSI.  The C2R O365 
update process via ConfigMgr needs some rethinking, and the Office 2016 patch 
process is the same as it has been for the last 10 years.

Sent from my iPad

On Jan 18, 2018, at 11:03 PM, Art Flores 
> wrote:

I am planning to start next month in production, got it working in the test lab 
using this link.

https://blogs.technet.microsoft.com/askpfeplat/2017/03/23/troubleshooting-office-365-proplus-patching-through-system-center-configuration-manager/

From: listsad...@lists.myitforum.com 
[mailto:listsad...@lists.myitforum.com] On Behalf Of Miller, Todd
Sent: Thursday, January 18, 2018 11:48 AM
To: mssms@lists.myitforum.com
Subject: [mssms] Office 365 updates basically impossible to deploy with 
Configmgr

Has anybody started deploying Office 365 updates via Configmgr?

I am finding that they are really problematic.  Updates seem to just start 
applying without warning, and the update will close all the running Office 
applications without notification.

The user gets a notification if the update deadline is a couple of days in the 
future, but once the deadline is past, the updates just start without warning 
and the office apps just close.

In many scenarios, the user will get no notification at all and office apps 
will just close without warning.

So a user fires up a laptop that has been off for a couple of days and opens up 
Word and Outlook to start her day.  Unbeknownst to the user a patch deadline 
has past while here computer was off and the update starts downloading.  10-15 
minutes into her day, the email she was just about to send is lost due to 
Outlook closing without warning.  And this is by design…

There can be many instance where a computer comes into scope for an office 365 
update after the deadline for that update has passed.


 I started looking into this and much to my dismay, it is operating as intended 
or at least designed. 
https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-office-365-proplus-updates

This is some kind of sick joke.   How can an organization operate like this?

  *   A notification icon displays in the notification area on the task bar for 
required apps where the deadline is within 48 hours in the future and the 
update content has been downloaded.
  *   A countdown dialog displays for required apps where the deadline is 
within 7.5 hours in the future and the update has been downloaded. The user can 
postpone the countdown dialog up to three times before the deadline. When 
postponed, the countdown displays again after two hours. If not postponed, 
there is a 30-minute countdown and update gets installed when the countdown 
expires.
  *   A pop-up notification might not display until the user clicks the icon in 
the notification area. In addition, if the notification area has minimal space, 
the notification icon might not be visible unless the user opens or expands the 
notification area.
  *   The notification and countdown dialog could start while the user is not 
actively working on the device, for example when the device is 

[mssms] 1709 Issues

2018-01-19 Thread Enley, Carl
We are currently starting to pilot the 1709 update to our users and have 
started to notice a few issues, I am curious if anyone else is seeing the same 
problems we are.

We are using 1709 Enterprise and SCCM 1706 task sequence to deploy, we have 
Office 2016 .msi version installed.

1 - After upgrading to 1709 our users are having search issues with Outlook 
2016, very similar to the issues last June when the security patch broke the 
search function. Basically when they search they have a message saying 
"Something went wrong and your search couldn't be completed", results are 
retuned but they appear to be missing some items. I was able to fix the issue 
by deleting the users .OST file and performing an Office repair, neither one by 
itself would fix the issue. This is really not a great solution as our users 
have pretty large .OST files and some of them are connected via slow WAN links.

Seems I may not be alone -
https://social.technet.microsoft.com/Forums/ie/en-US/c9673cdc-0fa9-4126-9acc-b9ec4ae3/after-windows-10-fall-update-1709-outlook-search-error?forum=outlook

2 - After upgrading to 1709 when a user is in Excel 2016 and they use the File 
> Share > Email to send the workbook via email they receive the following error 
"  General mail failure. Quit Excel, restart the mail system and try again". 
The only way to fic this is to delete the MAPI32.DLL file from C:\Program Files 
(x86)\Common Files\system\MSMAPI\1033\ directory.

Again it doesn't look like I am alone -
https://social.technet.microsoft.com/Forums/office/en-US/4ca08c76-5252-40a2-88bb-dd430d637c2b/general-mail-failure-quit-microsoft-excel-restart-the-mail-system-and-try-again?forum=Office2016ITPro

https://answers.microsoft.com/en-us/windows/forum/windows_10-windows_install/creator-update-excel-2016-general-mail-failure/07c820b6-3f5c-4a2d-bc2c-a051ec1effbf?auth=1

3 - My last issue is more of a product issue / feature request. While 
performing the 1709 upgrade over a VPN when the first reboot occurs the client 
loses contact with the MGT point, the task sequence continues to run and 
because I have the content downloaded before running the install succeeds and 
life is good. The problem with this is that the client does not queue up the 
status messages to be sent upon next connection to the network so our reporting 
is not reliable, we have no idea if the user is up to date via the monitoring 
tab...it gets messy as the systems stay in the "In progress" state.

I guess in an ideal world every user would be in an office somewhere connected 
to the corporate LAN while performing the feature updates but that is just not 
feasible in our environment as we have many road warriors and sales folks. I 
suppose some type of cloud / DMZ / IBCM type solution would help the situation 
but ideally I would expect the status messages to remain client side until the 
next time it connects to the MGT point and then send them up. Does anyone know 
of a script or something that could be run to re-send the task sequence status 
messages?

*Rant on/ - I have premiere support so I opened a ticket regarding the issues I 
am having, still waiting on response from MS but what I find ridiculous is that 
I have to open up 3 different tickets. So rather than working with one support 
rep I now have to mage 3 different support reps wanting to setup time to 
trouble shoot etc...all of the issues were caused by a simple 1709 feature 
update,  there should be someone who can take the lead and get the right people 
in the loop to help, why should I have to open and manage 3 different support 
cases because they broke core functionality in the product with the upgrade. I 
guess I understand the VPN status message thing should be a separate ticket but 
come on Office is Office and whether it is Outlook or Excel you would think the 
same guy could help me. *Rant off/