HPlum78

This issue is not a UK only issue for MS its way broader than that, the headline is also misleading in another way as the government in the Ukraine had already migrated a large chunk of their infrastructure to a private facility in Poland from memory. The broader issue for MS is one of ageing infrastructure and the same issue that every manufacturer/ service provider that needs silicone is facing and that is there is none... They have capacity to expand but nothing to expand with!

Will a Gator Grip socket not get on that? Save messing about with grinding sides of Allen's keys!

You will need to setup app proxy https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy I guess that you are already using MFA and therefore will have configured conditional access policies in Azure?

I don't know how many people have seen that Jeff is leaving Microsoft after ~22 years. To many of you who don't know the name he was the guy who invented PowerShell and was initially not liked for the idea of having Windows with no well Windows, amongst doing and being many other things at MS. I have had the pleasure of meeting him on a number of occasions and we spoke about all things PS, Cloud and AI related to name but a few, he has had a massive impact on what I do and the path that I took in IT. I wish him all the best, and if you guys have not come across him catch some of his PS talks on YouTube all very interesting stuff.

I have said this a number of times on here, moving to the cloud should not be and cannot be a lift and shift exercise. If you do that then you will not get any real benefit, especially if you are just replicating tin (IaaS). The real gains are from migrating services so if you run a website then migrate that to an IIS (PaaS) offering (if you are looking at Azure). Anyhow see my previous posts for more info.

At least in the latest movie they got Bogey and Bandit right, unlike in the first movie... Back on topic and keeping with military parlance: TITSUP

Breaker Rebooter Restarter :-p

I think the port thing has been answered, but I want to unpick the whole migration to M(O)365. So my first thought is data usage in my experience rarely goes down, but more interesting to me is if your talking Mailbox migration then the bulk of this work is done behind the scenes when migrating mailboxes the mailbox is synced and then you pull the trigger to complete the migration the user should not have any real down time (they will have to restart their mail client). If your going to do it you can start batching those migrations whenever.

Yeah I too have put it down to time of year and also remember my kids doing the same. As for a crate that's all very well and the conversation of right and wrong is one for another day for me.. I don't crate my puppy as it would stop him being able to grab hold of anyone stupid enough to not have me invite them in, 50kg 6 ft on his back legs @ 14 months old GSD needs to be able to do the job that he is here for and ensure that johnny robber falls in to the business end of making that mistake! :-p

My puppy wakes up at first light at the min and will make sure that he gets me up so he can go for a walk!

You should hopefully be using the v2 Exchange online module and have run the connect-ExchangeOnline command to connect up a session to EXO?

The issue here is if any objects have been created on the failing DC when you demote that DC those objects will also be deleted /lost or any updates that have happed on any objects on that DC would also be lost. I don't know how busy your Domain is but the scope and scale of this will depend on that... Another consideration on the same note is if your using AAD Connect and syncing your users/ groups (objects) to Azure if this is bound to the failing DC this to could have implications (even if its not this could still cause some issues mind) on the integrity of what is being synced. I would need to spend more time understanding what has gone on, but those are my initial thoughts. Tread carefully here as you may introduce a whole new set of issues and I would not just go demoting and promoting DC's.

Yeah I have also seen them a number of times an all, seems like they have been around forever and yet he was only 60! Sad news.

https://www.bbc.co.uk/news/entertainment-arts-61597992

Oh and just for completeness you could also use the following as long as your using Win PS v4.0 or later and PS v 7.0 and later: $titleArray = @() $titleArray = 'HeadTeacher','Senior Leader','Business Manager' Get-ADUser -properties Title,extensionAttribute10,Displayname,department -filter * | where-object -property Title -in $titleArray This is the new way of using where-object that was introduced in later versions of PS and is more human readable than using the script block method.

Seems all overly convoluted to me can you not do something like this:- $titleArray = @() $titleArray = 'HeadTeacher','Senior Leader','Business Manager' Get-ADUser -properties Title,extensionAttribute10,Displayname,department -filter * | Where-Object {$titleArray -notlike $_.Title} And I am pretty sure that you will be able to do -*contains -*match an all, ain't tested any of this so happy to be told otherwise.

If you use Azure the KeyVault

https://plumsail.com/sharepoint-helpdesk/

Yeah I love the MAY MIGHT statement an all! Lots of scope in those words.... makes a mess of DEV TEST LIVE

After installing updates released May 10, 2022 on domain controllers, you might see authentication failures on the server or client for some services. These services include Network Policy Server (NPS), Routing and Remote access Service (RRAS), Radius, Extensible Authentication Protocol (EAP), and Protected Extensible Authentication Protocol (PEAP). An issue has been found related to how the domain controller manages the mapping of certificates to machine accounts. Note Installation of the May 10, 2022 updates on client Windows devices and non-domain controller Windows Servers will not cause this issue. This issue only affects servers that are used as domain controllers. The preferred mitigation for this issue is to manually map certificates to a machine account in Active Directory. For instructions, see Certificate mapping. Note The instructions are the same for mapping certificates to user or machine accounts in Active Directory. If the preferred mitigation will not work in your environment, see KB5014754—Certificate-based authentication changes on Windows domain controllers for other possible mitigations in the "SChannel registry key" section. Note Any other mitigation except the preferred mitigations might lower or disable security hardening. The above is from the support page worth being aware of.

Or if you really don't want to pay set up an SMTP box on prem.... oh and don't use the Windows SMTP service as this is being disbanded. https://www.hmailserver.com/

Yeah I hear this all the time 'I have found this code on the Internet...' I shudder take a deep breath and hope all I see is get- :-p

Jeff Snover says this "The reason why PowerShell has a -ExecutionPolicy BYPASS parameter is to make it absolutely clear that it isn't a security layer." And he knows a thing or two about PS... https://devblogs.microsoft.com/powershell/powershells-security-guiding-principles/ The above may help.

You have probably seen the banner in your Azure tenants, MS was due to remove access to the Azure AD graph API endpoints on the 30th June this year. They have now announced that this is being pushed back to ~December this year but it is worth noting that they are still going to remove the ability to manage some aspects of Azure on the 30th June still. Most notably is the licensing assignment endpoints, so if your using the MSOnline/ Azure AD PowerShell modules (set/new-MsolUserLicense or the set-AzureADLicense CMDLets) in anyway to manage your user licensing then you need to be sure to migrate these to the new Graph API endpoints/ Microsoft Graph PowerShell module. That said if you are still using the msol/ Azure AD modules it is time to start thinking about migration to the new modules.

Ground