LeeAU

We're rolling out the hotfix today although I've seen some people with this issue still report crashing after the upgrade. Apparently Forcepoint are aware of the issue and working on a fix.

We use ForcePoint however this has not been changed or updated. What are you using?

Interesting, this seems to be a widespread issue and I'm convinced MS have changed something on their end. Our premier support has not been much use either. There are also more people affected, see these threads: https://community.spiceworks.com/topic/2209165-outlook-crashing-across-entire-domain?page=1 https://answers.microsoft.com/en-us/msoffice/forum/all/outlook-2016-cashing-for-multiple-users-over/5d2a6b53-3b86-45e4-b9ef-34f95711dfcf?rtAction=1557323798491&tm=1557324341295&page=1 What I have done as a temporary measure is enable the following GPO and created a group called "Disable All Outlook Addins" and put any users who get the issue into it. User Configuration > Administrative Template > Microsoft Outlook 2013 > Miscellaneous > Block all unmanaged add-ins User Configuration > Administrative Template > Microsoft Outlook 2016 > Miscellaneous > Block all unmanaged add-ins This seems to work for now while we find an actual fix for the problem.

Event viewer just gives generic errors, such as: Add-in execution error. Outlook crashed during the 'Open' callback of the 'ItemEvents_10' interface while calling into the 'Microsoft Teams Meeting Add-in for Microsoft Office' add-in. Our older Windows 7 machines were built using imaging software Acronis then joined to the domain. We now use MDT to deploy Windows 10

Around 29th April, Outlook 2016 has started crashing on random machines across our entire domain. The error is "Outlook detected a COM add-in problem" as seen below: As you can see it's telling me all of the add-ins are causing problems - even the Microsoft ones! This is happening on Outlook 2016 on Windows 7 and Windows 10. What I've done so far to try and fix the issue: Created new local profile & mail profile Deleted Office and Outlook folders in %LOCALAPPDATA% and %APPDATA% Disabled Sophos anti-virus Confirm no Windows/Office updates were installed lately Disabled all add-ins in registrty by changing the "LoadBehaviour" keys to 0 Ran an offline & online repair of the Office install Completley uninstalled office using the office removal tool & re-installed Ran the Microsoft Support and Recovery Assistant for Office 365 tool I'm quickly running out of things to try and would appreciate any suggestions

Googled it and managed to get it working, it is much faster! thanks a lot. This will come in handy in future scripts

Windows 10 Pro x64 and PowerShell 5.1.17134.407 Yes, from my workstation. How would one go about this? Is it just an extra line I need to input?

I'm trying to give our Service Desk guys full control of our user profile and home directories by running a PowerShell script. This is the script I'm running: $Acl = (Get-Item "\\MYSERVER01\Profiles$").GetAccessControl('Access') $Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("MYDOMAIN\ServiceDesk", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow") $Acl.SetAccessRule($Ar) Set-Acl -path "\\MYSERVER01\Profiles$" -AclObject $Acl I am running it on a total of 90 servers. The problem is the script has now been running for two weeks and is only around half way through! Running the above command on one server individually takes hours and hours. There isn't a lot of data in the users profile and home directories either. I can't work out why it's taking so long for the script to run!? What am I doing wrong?

Yes, I've double check and the subnet mask and other NIC settings are all ok, it's really weird!

I have an issue with a network drive not mapping for users when logging in through Microsoft RDS. Our network drives are mapped through single a GPO that uses item level targeting and maps it to all users in a specific OU. I have run a gpresult /r and can see that the GPO is successfully applying, and the other mapped drives specified in the same policy map successfully. It’s just one drive that isn’t mapping (G) – and this only happens when the user is logged in using remote desktop, when they’re logged into a workstation (either Windows 7 or Windows 10) all of the drives including G: map successfully. Upon further investigation I've found that our Microsoft Remote Desktop Server(s) can no longer access one of our file servers - FILESERVER01 / 192.200.1.20The hostnames/IPs of our RDS servers are (They are set up with load balancing): External - RDS.MYCOMPANY.COM.AU Internal - RDSSERVER01 / 10.202.180.21 & RDSSERVER02 / 10.202.180.22 (They are set up with load balancing) The RDS servers can access everything else fine such as FILESERVER02, EXCHANGE01 etc. It’s just FILESERVER01 that it can’t communicate with, and FILESERVER01 can’t ping any of the above RDS server addresses either.I've checked DNS, DHCP, AntiVirus, LMHOSTS file and our Firewall and everthing seems to be in order with those...