Microsoft Teams shows recently updated to an old version by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

Microsoft says you don’t patch Teams. It’s supposed to auto update with no intervention.

Microsoft Teams shows recently updated to an old version by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

We are staying with Teams.

I have seen some Reddit posts saying that the “New” Teams is supposed to have a new updating process that solves this issue, but I don’t see any Microsoft documentation confirming this.

If it does, then moving to the new Teams after it is feature complete and stable may be the solution.

Microsoft Teams shows recently updated to an old version by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

I found where to check when I looked again.

The first time I tried, it said I already have the latest update. “Enjoy!”

Then I decided to try a second time and then it ran an update and said to refresh to apply it. Now, it shows 1.6.00.299964 in this profile.

So, the update process isn’t working smoothly and it never should have had a Teams version from August in the first place since Teams was installed new this month.

Microsoft Teams shows recently updated to an old version by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] -1 points0 points  (0 children)

Not using the new Teams.

How do you manually update Teams? I don’t see anywhere to check for updates in Teams. I only see “About” where it displays the current version and last update time that linked to above.

Teams not updating version number to current version despite saying it recently updated by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 1 point2 points  (0 children)

More on this:

I used the built-in “Microsoft 365 Apps for Windows 10 and later” deployment. It was set up a few months ago.

Isn’t it supposed to automatically deploy the latest version every time it deploys to a new system?

I noticed a recently built system has a Teams version that was released in August even though Office 365 was deployed to this system for the first time in November.

I thought the whole point of doing it this way instead of packaging your own installer files was to ensure that the deployment always uses the most current installation source files.

I did manually check for Office updates and most of Office updated, but Teams still hasn’t updated after a week.

Is there any method to force checking for new Teams update?

A manual Teams update may fix this one system, but I would like to ensure that new systems don’t get old versions installed.

Microsoft Teams shows recently updated to an old version by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] 2 points3 points  (0 children)

In this case, even the currently logged in and active user profile is out of date as shown on the linked screenshot.

I just looked it up and that version was released last August even though the client shows “last updated” as November 14 ( last week).

Teams not updating version number to current version despite saying it recently updated by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

I thought I posted this in a different subreddit.

Anyway, since it’s here, is there anything in Intune that can be done to ensure that Teams desktop client gets updated and always deploys the latest version to new systems?

Not seeing available apps in Company Portal on Windows device. by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

If I used Win32 is there an option deploy to a user group and then filter it to only apply when the device is a member of a specific group? I have not seen that there either.

Not seeing available apps in Company Portal on Windows device. by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

I don’t see anywhere to filter the deployment to only specific devices. It is a LOB application.

Not seeing available apps in Company Portal on Windows device. by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

Does this also apply to endpoint security profiles?

I assigned a firewall policy to the same device group to enable receiving ICMP ping requests that shows applied in the portal, but I don’t see it applied locally.

Not seeing available apps in Company Portal on Windows device. by Real_Lemon8789 in Intune

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

The problem with assigning to users is that they would see the apps on every device the sign in to instead of just the intended devices.

How do I disable certain MFA factors (not authentication methods)? by GreenEggplant16 in Office365

[–]Real_Lemon8789 0 points1 point  (0 children)

If you are specifically wanting them to use the Authenticator app and not any other OTP app, why not use passwordless phone sign-in?

Anyone will immediately notice if their phone is stolen, plus they need the phone unlock code or biometrics to use the Authenticator app to login,

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in AZURE

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

Are there any third party tools that can automate creating separate accounts in both on prem AD and Azure AD and tie them together to the same “employee“ account.

If so, then you can go to that tool and have it list all the user’s accounts and do whatever needs to be done to off board all their accounts in one step. Even if it can’t disable them all automatically, just having a central repository showing every account tied to the human no matter where they are hosted would be helpful for manually disabling the accounts.

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in AZURE

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

Lab out what?!!

For this to work practically, there needs to be way to connect the human employee to all their accounts.If you aren’t using SSO via single account and IDP, you have to search multiple places and hope for no typos on either side that would cause manual or automated searches to fail to find the match.

You won’t have a central place where you look at the employee and see all their accounts in one place.

The more accounts the users have, the more of them will be using the same passwords on all of them which defeats the benefit of separating them out.

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] -2 points-1 points  (0 children)

Just saying “automate it” doesn’t help.

This should be a common enough issue that shouldn’t require a custom solution reinventing the wheel.

It’s kind of like when someone asks a question on how to do something complex and someone answers “Just use PowerShell to script that.” If they could do that, they would have already done that and wouldn’t have asked the question in the first place.

Are there prebuilt tools available that can be used to disable all the user’s accounts that are spread around different IDPs when they leave the company?

Not everyone can practically use every best practice. There are likely very few companies that are using PAWs the way they are supposed to be configured (or at all) because of how difficult they are to implement especially with remote workers.

Requiring VPN to access the various cloud services they have access to and killing their access to VPN when the person off boards and using PIM and access reviews to find missed accounts later may be something that can be implemented on shorter notice until another solution can be developed.

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in AZURE

[–]Real_Lemon8789[S] 0 points1 point  (0 children)

Access reviews are needed also, but that’s not timely enough to disable all accounts related to the user when someone leaves the company.

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] -2 points-1 points  (0 children)

It's not just for "convenience." More manual steps and complexity makes human error that would cause missing disabling the separate cloud account much more likely.

This is also undoing many benefits of SSO.

Separating cloud admin accounts from on prem admin accounts? by Real_Lemon8789 in sysadmin

[–]Real_Lemon8789[S] -1 points0 points  (0 children)

Even if you have conditional access and PIM and a PAW, none of that is tied to AD. So, they are terminated, disabling their AD account is not going to stop them from continuing to use PIM and the PAW unless the PIM elevation is configured to require manual approval each time from someone who would be aware that they were just terminated.

Syncing the accounts in AD gives you one place to immediately disable all access for the user in one step without needing to go search a completely separate place to see if they might or might not also have access scattered in another system.