While I agree to an extent, I've reached a point with intune that I can deploy pretty much anything. Including certs and even local printers on the print server.

@@jgould30how do you deploy local printers with Intune? That’s been a pain for me for years.

@@ACBCallahan I just literally went through this and I ended up setting up PowerShell scripts to detect, install, set default preferences, and remove the printers as an Intune Win32 App and works like a charm.

@@kingdavid52was this using a local printer server or adding by direct IP? Would love to chat more if you’re willing.

Welcome aboard!

Exactly. Take a look at this video for an update: Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!! kzfaq.info/get/bejne/bJx5ZbNnvdC4qY0.html

PDQ Inventory and Deploy support non-domain joined devices (as does ConfigMgr actually). You just need to add the local admin info to PDQ. See below: help.pdq.com/hc/en-us/articles/360058301191-Working-with-Non-Domain-Workgroup-Machines

Should have been more clear. I had connectivity because I was in the same vlan. This was simulating using a “cloud only” device, but being in the office.

No, CM1 was just an example of a file share. Any on prem fileshare should work. I don’t actually have any enterprise printers at home to test with, so I can’t verify that with a video, but I know a lot of organisations who do have printer access working from AADJ only devices.

The requirement is for the user to be synchronised via AAD Connect. The device identity isn’t being used here. Try it out… 😀

Agreed, so simple. 👍😀 I plan to make a video demonstrating how to manage co-managed devices on the internet, which will cover delivery optimisation and that kind of thing. It should be done in a few weeks

Eagerly waiting for a video on Dlvry optimazation 👍

@@someshpahak +1

Good questions! I admit I could have explained the set up a little better now that I’ve had some great feedback like this. The user was born on premise and synchronised it Azure AD, so the DC was the authority for that user. So yes, whilst we don’t need to join a computer to the domain to access on premise resources, the demo I gave here does require the user to be born on premise, and synchronised to AAD. I did have connectivity to the DC when testing.

@@theCMC Thanks for the quick answer. Congratulations for your channel. You are doing an amazing job. I have seen some other videos regarding OSDCloud and those are very, very interesting. Keep going.👍

Wow times have changed for the better. What domain level are you running in this lab?

@@rob-123 I think it’s 2016 FFL

Yes - file-shares, printers, web apps, most of the stuff users need to access on-premise is accessible via AAD-only devices, without much configuration. GPO is a different topic, but that's a fantastic suggestion! In summary, my belief is that GPO is not required. If you're on Twitter, follow Kim Oppalfens (@TheWMIGuy) for some fantastic insight on the topic. Whilst GPO is not required, we can leverage Intune, proactive remediations and baselines to achieve a goal. The question is (as Kim discusses), is the goal in the Modern world, the same as the Old world? I shall do a video on the alternatives to GPO. Thanks Imran.

Great question. Yes - Azure AD Connect is in place on a separate server to handle synchronisation of users. The users I’m showing are on-premise users that have a synchronised identity. Other than that, there is nothing configured to specifically allow this demo to work. It is all handled natively, and that’s the point I’m trying to get across in this video. Azure AD devices are much more capable that some organisations think…

So to be clear, the users are still on-prem users, synced to Azure AD? Our issue is users that are just in Azure AD that need to access on-prem resources (files and RDP). It seems that's still not possible.

@@timwhite8 yes. On prem users that are synced to the cloud. I haven’t tried an AAD only user; I’ll try that next !

@@theCMC And it definitely wasn't a jab at you just to be clear. Just want to make sure that less senior people aren't seeing this video and thinking that all they need to do is just connect to the resource. There are other backend things that are at play, but I do love the intent. We run across clients all the time that for some reason want to hold on to the legacy idea of doing things and lean straight into the Hybrid join conversation so I have to remind them those legacy ways have drawbacks such as line of sight with the domain controller to allow authentication while cloud-only means you can be anywhere in the world and authenticate.

@@tbrown4305 no problem, I love the questions and think they help the audience understand the concepts better. I’m only one person, with one view and perspective, and I’m willing to learn in public. That said, it looks like we have the same thoughts on this one; i just wanted to make a video with a very specific point :-)

For user identities, those on-prem characteristics still exist if you use hybrid users, even without hybrid devices.

You're welcome. It's probably best for you to read this incredible series by @byteben - there is a section on the issues with WHfB. msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/

Intune is awful at software inventory. Defender for Endpoint is better, but no where near as good as ConfigMgr. Have you considered ConfigMgr?

Intune is our new baby, it will replace the Desktop Central which has the edge in terms of software and hardware inventory

Ninja One (RMM) provides an accurate Software Inventory

Hi Michael, AADConnect was configured to use Password Hash Sync, not Passthrough. For more information, please see this blog by Ben Whitmore and Michael Mardahl. msendpointmgr.com/2021/08/15/sso-to-domain-resources-from-azure-ad-joined-devices-the-mega-series/

The demonstration here relies on the User identity being based on an on-premise DC, and line of sight with a DC is required, yes.

Hi Julio, This is possible, but probably not via the the current method that you’re using to enable the device to auto enroll for a certificate. Instead, you’d need to leverage Intune to deploy a certificate via SCEP or PKCS.

This video shows how you can access file shares hosted on-prem from Cloud Only computers. The computers still need network access to the file share, so any solution will always need you to either have the computers in the same network location, or be accessible by some routed network or VPN. In your case, placing the fileshare in Azure won’t mean that Cloud Only devices can access it. The location of the file share is not the factor that determines this, as you need to ensure that the computers can access it anyway. If you’re moving the fileshare to Azure for other reasons - such as downsizing your own hosting perhaps - then that’s fine. Just be aware that you’re not solving the access problem, you’re just changing it.

Do I still need a domain controller in azure or can I just use azure AD to Join cloud based computers and still have access to azure file server shares

A domain controller in hosted in Azure is no different from a domain controller hosted on-premises, from that perspective. Use Azure AD. I assume you mean Windows Server Fileshares hosted in an Azure VM (as opposed to Azure Files). Perhaps this video will also help? kzfaq.info/get/bejne/bJx5ZbNnvdC4qY0.html&lc=UgwOs8-91APY4ywQbcV4AaABAg

Implement windows hello cloud trust, that way they can access on premise resources with hello

Yes. Do that. I made a helpful video. It’s super simple. Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!! kzfaq.info/get/bejne/bJx5ZbNnvdC4qY0.html

Yes. Your users are domain users still.

This depends. As you can see in the video, the users domain identity is recognised by the on premises resources, like file shares. The computer device identity will not have an on premises account, however.

@@theCMC Thanks for your reply. Yes I can see that file access is possible. We need to use an application on the laptop which required to add an a Domain Windows ID to Local Administrator group and also to DCOM setting. Does it mean that it's not possible or there's actually need some setting required in Intune manager?

I think you may be over-thinking it. Apologies - I could have explained the scenario a little better in the video! We have some servers on-premise, joined to a domain. They host a file share. We have a Windows 10 computer, which is not domain-joined, but is Azure AD joined. I put them in the same LAN so that they could communicate directly; similar to if the Windows 10 device was a laptop of a user who was sat in the office, and the office had connectivity to the server hosting the file share. In that scenario, it just works. There is no trickery or magic - it just works. That's the point I'm trying to get across here. HOW it works, is another matter. I intend do a video on that another time 😀

@@theCMC ahh you were on the same LAN, understood! For remote users I guess a VPN would then suffice. Cheers 👍

Yep, remote would require a VPN. I'm hoping to do a demo of accessing remote stuff later - this was really just stating and demonstrating something simple, yet often misunderstood.

@@theCMC appreciate it. Thank you

Sounds sensible. So you could cloud join all devices except the admin devices?

Thanks Nazid, Why am I against Hybrid AD join? Firstly, password resets are a pain, as are forgotten passwords. The device must be in the office or connected to a Device VPN to use the user's new password. Aside from that, you're right - there many cases where Hybrid Devices are required. GPO is a great example. This video is not aimed at those engineers, architects or organisations that have thoroughly evaluated whether Azure AD will work for them. It is aimed at the 95% of organisations that assume Azure AD can't do X, where X is file-shares, printers, web-apps. Aside from some niche GPOs (or a large number of niche GPOs), I (personally) don't believe there are any advantages of Domain Join over Azure AD Join. If there are, in your view, I'd love to discuss them. We're all learning here, and I appreciate the comment. /Dean

The user accounts just need to be synchronised to Entra ID / AAD for them to be able to log into a cloud only (AADJ / Entra ID joined) device.

It depends. This video was about not hybrid joining devices. You should probably still have on-premises users and sync them to the cloud. That’s a good idea. But let those users (with synced credentials) use cloud only devices. They can still access on-premises file shares and apps using their on-premises credentials.

Do.... what?

Thanks. No, that was genuine surprise. As is the theme of most of my videos, I’m not an expert in all areas that I cover, and am learning as I work through some of the specific areas that I think people might be interested in. I had expected the device to prompt for credentials as I had not enabled SSO in Azure AD connect (as did some of the others watching and commenting on this). My plan was to have the prompt appear, then explain that I would need to enable SSO to get it to be seamless…. It turns out that it actually does just work, even without SSO enabled. I’ll be doing a video shortly where we we break down how that all works, now that I’ve looked into it :-)

@@theCMC awesome. This is my first video of yours and I'll plan on watching more. Thanks

This video explains a little about how you should configure this with the latest capabilities: Hybrid cloud Kerberos trust deployment - Say NO to Hybrid Azure AD Join!! kzfaq.info/get/bejne/bJx5ZbNnvdC4qY0.html

Very true! There are some clear reasons where Domain Join is required. The idea of the video was to challenge the default mindset when moving to Intune managed - hybrid is not required… until it is.

Indeed. Just don’t use GPO :-)

noted :-) /Dean

I fixed this in my latest video on this topic 🙂

Domain Join doesn’t always save time and resources when compared to Azure AD Join.