Limit who can post in general channel of Microsoft Teams

As we know, each Team of Microsoft Teams include a General channel, by default all users can post in that channel, but you can limit who can post in that channel. For example imagine that you want to use that channel to post the rules of the Team.

In each Team, we can configure the following levels:

  • Everyone can post (the default setting)
  • Everyone and display an alert that everyone in the Teams will be notified
  • Just the Teams owner

To change the default permissions we must be a Team owner and do the following procedure:

  • Select the 3 dots of the Team, then Manage Team


  • Settings, under Member permissions, we can see the 3 options, select which option fits better to your Team


And it’s all set!


Mainstream support for SharePoint & Project Server 2013 will end in 4 months


Yes, you’ve read it well, mainstream support for SharePoint 2013 will end on April 10th of 2018, after this date only security fixes will be provided for SharePoint 2013. Regular hotfixes in case some bugs have been detected can no longer be requested.


*Image extracted from:

If you haven’t already planned to migrate  to SharePoint 2016, this announce should change your mind.

This is not the only thing to consider after this date: starting with April 10th, 2018 the required patch level to request support for SharePoint 2013 will also change.

Currently all patch levels starting with SharePoint 2013 SP1 are supported. Starting with April 10th, 2018 this will change. In order to request support from Microsoft after April 10th, 2018 the SharePoint server farm has be on a patch level of April 2017 CU or later. A year later, after April 10th, 2019, the SharePoint server farm has be on a patch level of April 2018 CU or later.

This change is outlined in the Updated Product Servicing Policy for SharePoint 2013 published on TechNet.

So keep in mind this piece of advice and update or migrate your current farm!! 😉

Back to ADFS Certificates

Hi there!

ADFS certificates? Yes! They come back to me as little nightmare xD, but in the end, this time was pretty simple to solve it.

The problem begun with a client call that I planned to visit the same day (for other reasons), and he was in panic because the certificates associated with the CRM and ADFS needs to be updated, since the day after will expire.

At the beginning I though, “I don’t have any idea about CRM and how to update the certificates”, but having a technical background I decided to tell him that after the meeting we could have a look to the CRM and the ADFS farm to see what was happening.

Once I finished the meeting with him, I meet with the person in charge of updating the certificates, he explained me how he updated the certificates in the CRM, but he still has a problem with the certificates in the ADFS farm, for me it was like light in the darkness, I don’t need to deal with the CRM, only with ADFS!! 1 point!

Looking to the ADFS farm, the first thing that I realized it was that he updated the decrypting and signing certificates, but the service communications shows a message saying that “It is not possible to find the certificate”. Weird… the client told me that he imports the certificates in the personal Store, so the certificates exist.

If you tried to associate a new certificate with the button “Set service communications certificate”, it fires an error in the ADFS console, but it doesn’t write anything in the event viewer. I started to check in the IIS (it was a 2.0 ADFS) the certificates, I realized that in the binding, the certificate was not associated, I associated it, okay.

Come back to the ADFS console, and try to re-associate the certificate, no luck.

I was pretty sure, that the problem was with the certificate associated, so I starts to look into my PowerShells, one PowerShell to reassociate the CS certificate by scripting, since the interface does not work. But by the time, I asked to the client if he still conserves the old certificate that he delete it, he say yes, and I asked him to reimport it again to the store.

Once the certificate was imported again, I refresh the ADFS farm… and bang!! The CS shows the old certificate, great, then my following action was to try to set the set service communication certificate, and bang! It shows the dialog where is it possible to see the old certificate and the new one, I selected the new one and finally I restarted the ADFS service.

I tested with the CRM, and it was possible to see that it connects with the new certificate 😊. So… what I learned from this experience? Never delete a certificate without first renewing it and test that everything is okay.

By the way, I found the PS to set the CS certificate, but it was not necessary to execute it:

Set-AdfsSslCertificate –Thumbprint <ThumbprintCertificate>

Set-WebApplicationProxySslCertificate –Thumbprint <ThumbprintCertificate>

Azure classic portal will be deprecated

If you are still accessing to the classic portal to manage your VM’s and resources, be aware that the classic portal will be deprecated during the next month. The following information has been published in Docs:

The Azure classic portal will be retired January 08, 2018. After this date, if you attempt to use this portal, you will be automatically redirected to the new Azure portal.

For more information, see the blog post announcement, Marching into the future of the Azure AD admin experience: retiring the Azure classic portal. For the temporary extension to the original retirement date, see Update on retirement of Azure AD classic portal experience and migration of conditional access policies.

So take into consideration to assess your client to migrate all the information or control those applications that still in the classic portal.

Getting the best connectivity and performance in Office 365

In all the O365 adoption projects where I have the pleasure to be involved, there are always questions about how the network will affect to users. It is necessary to consider that for business is a big step to go from resources allocated On Premises to all their resources allocated somewhere in the cloud.

So, it is normal that the IT department will be afraid when they must affront this change, more in particular, as I said at the beginning in the network part. In general, doing a network assessment, will clarify the vision to the clients and, they will be more confident about the change.

But, it is recommended to give them a series of guidelines, to understand better how works the suite and which networking elements will be involved in it. I strongly recommend the following post in technetcommunity about this topic.

Connecting to Office 365/Exchange

EighTwOne (821)


Last update: Version 1.81, November 16th, 2017

Almost 3 years ago, I wrote an article on how to enhance the PowerShell Integrated Scripting Environment, or ISE. That seemed adequate for the Exchange admin back then, who mostly connected their PowerShell session to their his on-premises environment, and perhaps occasionally a bit of Exchange Online.

Fast forward to 2015, most modern Exchange administrators not only require a connection – if any – to their Exchange on-premises environment, but likely to one or more of the Office 365 services as well, including Exchange On-Premises, Azure Active Directory, Exchange Online Protection, Microsoft Teams, Skype for Business Online, SharePoint Online, Azure Rights Management Services or Compliance Center.

All these services use a different PowerShell session, use a different endpoint FQDN, and in some cases require a locally installed PowerShell module. Likely common denominator is the credential used to access each of these services. So…

View original post 616 more words