IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hey y’all, Mark and Tom back with our second Friday mailbag. So far so good on trying to keep our regularly scheduled mailbags. We even got a few other PFEs to join in for this one so let’s get right to it. This post will cover the following.
Can we host DNS in something other than Active Directory? Something like BIND?
This discussion tends to move from a technical one to a “religious” one very quickly. The technical answer, Yes you can as long as the DNS hosting meets the requirements listed at http://technet.microsoft.com/en-us/library/cc739159(v=WS.10).aspx. BIND does and lots of other 3rd parties do as well so there is no technical reason why you can’t. However this tends to be a battle over political power or whatever your “religion” tends to be, Microsoft, BIND, etc. Many times I’ll go to have a DNS discussion and the other group already has their guns blazing ready to go and are pleasantly surprised to find out that it is ok. Remember, stick to the technical facts and you’ll be just fine.
Is there a way to use all those AD commands I know and love like repadmin or netdom but in PowerShell?
Mr. Ashley McGlone aka Goatee PFE has got you covered with a nice document of command to PowerShell equivalent that you can print out and put right up in your cube. Grab the latest here.
I recently read your ADFS Lab part 4, http://blogs.technet.com/b/askpfeplat/archive/2014/03/31/how-to-build-your-adfs-lab-part4-upgrading-to-server-2012-r2.aspx and wanted to know how long can we run with both ADFS 2.1 and ADFS 3.0 running before cutting over. Anything I need to worry about?
I’m turning this one over to one of our ADFS experts, David Gregory.
“The nice thing about standing up ADFS 2012 R2 in parallel with the prior version infrastructure is that it gives you an easier failback in case anything goes wrong.”
There are three things that really matter here:
1) How are you getting the relying party applications from the old ADFS farm to the new ADFS farm?
2) Are you keeping the same federation service DNS name for the new farm?
3) Are you using the same token signing certificate for the new farm?
For #1, if you’re migrating to ADFS 2012 R2, I highly recommend you use the built in scripts to migrate the relying party trusts and other configuration including certificates over to the new ADFS farm. If you want to migrate the token signing certificate over as well, you will need to use the same ADFS service account on the new farm so it has the right permissions to the private keys of the certificates. Here is our documentation on using the scripts to migrate over the old configuration:
If you decide not to use the scripts to migrate the relying party trusts over, you can recreate the O365 relying party trust by running the following:
Type in your Azure AD admin credentials.
Update-MSOLFederatedDomain -domainname <domain.com>
If you used the migration scripts and you answered Yes to #2 and #3, then you can cut over at any time by changing the DNS records. You’ll want to decrease the TTL on those DNS records leading up to the cutover, which enables a quick cutover and failback, if necessary. The failback would be to change the DNS Host (A) records back to the older server IP addresses.
If you answered Yes to #2 and No to #3 perhaps because you didn’t use the migration scripts, you’ll want to make sure all your relying party applications have the new token signing certificate before cutting over. If you are federated with O365, you’ll want to run the Update-MSOLFederatedDomain cmdlet on the new ADFS infrastructure first. Then you can change the DNS records to point to the new infrastructure like I recommended above. Once again, make sure you decrease the TTL on the DNS records well before the cutover. This route does make the failback plan more difficult because you’ll need all your relying party applications to revert back to the old token signing certificate. Once again, the failback would be to change the DNS Host (A) records back to the old server IP addresses and revert all relying party applications back to the old certificate. If federated with O365, you’ll also want to ensure O365 has the old certificate by running the Update-MSOLFederatedDomain cmdlet on the old ADFS infrastructure.
If you answered No to both #2 and #3, you definitely aren’t using the migration scripts so it’s like standing up a new infrastructure. You’ll obviously want to create the DNS Host (A) records for the new infrastructure ahead of time and the switch over will occur as soon as you run the Update-MSOLFederatedDomain cmdlet on the new ADFS infrastructure. The failback for this scenario would be to run the Update-MSOLFederatedDomain cmdlet on the old ADFS infrastructure.
Regardless of what route you take, I would highly recommend doing this on the weekend, which would give you some added time to test all the federated applications before going live again.
Good advice, especially on the weekend.
Does my laptop need a new battery? How do I tell?
PFE Joao Botto has just published a script that captures information about the capacity that your battery should hold by design and the capacity that your battery held on its last full charge. The script then computes the percentage of charge that your battery can still hold and saves that information in the registry, in a file, or simply print it on screen. Feel free to collect that information through System Center Configuration Manager or any other tool to easily know what PCs in your environment need to have their batteries replaced.
-Did you know you can get unlimited storage on Microsoft OneDrive? Because you can.
-A great web series called Comedians in Cars Getting Coffee has just started Season 5. It’s Jerry Seinfeld and another comedian doing what comedians do, being funny. Make sure to check the back seasons if you’ve missed them. You’re welcome.
-Did you ever blow on your Nintendo games to make them work? Ever wonder why? One of my absolute favorite blogs, It’s Okay to be Smart, explains why you probably did this. Science!
-I’ve been slimed! This might be the best Ghostbuster merchandise ever. They even glow in the dark!
Sends us your questions and things you’d like to see covered.
Mark “There is no Dana” Morowczynski and Tom “Only Zool” Moser