Day 2:

A nice Microsoft person contacted me directly, just to be sure I had everything I needed for this trial.  I told him yes; I'm just testing and getting familiar with it.  If I hit some horrid snag I'll just go ask in the CM forums.

The policy made yesterday for "configuration" was Android Policies; and it was targeted to a group that contained a test user, not a device grouping.

Downloaded the Company Portal on an Android phone (Samsung S4), signed in with the user account created yesterday; the one which deserves the Configuraton Policy.  That ConfigPolicy I made custom--with only 2 very easy-to-see settings. After signing in, and going through next/next/finish on the phone, confirmed the 2 changes were enforced.

Even with currently only 1 device--much of my work life is creating reports.  Over the years, I just got good at 'knowing' where in the database information was stored, and how best to extract it when parameters change.  So in, there's a reporting section.  Now that I have 1 thing to look at; time to start poking about.

Created a report for "all Devices, All publishers, All Categories".  This was created at least an hour after the device got policies, but there are zero results.  Is there something additional I need to configure?  Or does this only work for certain devices, and Android isn't one of these devices?  Or is that report only for Apps as deployed by Intune--which I haven't deployed any yet.

I do see the 1 device in the "Mobile Device Inventory Reports".  So maybe it's just time--I need to wait for the device to do an inventory and send it up. 

Since I can't see any software yet in reporting, just recording the portals that I've so far had to get to: -- Office 365 -- to create users and usergroups for Intune standalone to leverage -- the main Intune (at least how I think of Intune) portal.

Added another mobile device--this time a Galaxy Tab 4; I'm sure it'll get the policies just fine.  I'm more curious about what I see in reports.

Just some user experience stuff, when signing into the Company Portal, the "Activate Device Administrator" lists a lot of scary-sounding permissions; but that's only because I'm so used to Android devices being unmanaged/wide open.  But I've also become jaded to the 'permissions needed' on Android since the latest updates to the Android OS.  It's kind of like click "I agree" to those legal license notifications--you just don't read them anymore.

Well, I've waited about 3 hours since having those 2 devices get policies--and still nothing in "Detected Software Reports".  I'll let them hang out overnight--maybe that's a "every xx hours" thing or something, and I'm just too impatient. 

When Intune was beta, I tried a trial at the time--which was well over a year ago.  Since things change--including me--I decided to try another 30 day trial.

Back when I was looking at it over a year ago; my priority at the time was to see if it could be capable of 'fitting in' with the needs of managing a full 'pro' or 'business' version of Windows 8.  The mobile management pieces of it weren't that interesting to me; it wasn't part of the landscape for me at work, and quite honestly I didn't have personal devices to test with.  I still don't have a full range and scope of personal test devices; but tally-ho anyway!

Here's my new premise (subject to change of course--this is testing).
- Use Intune Standalone only, not hybrid to the home lab
- Get familiar with the console
- Reporting
- Policies
- Management: users or devices or combination

I know that Intune works--it clearly works fine.  It's my journey to understand how it works with my on-premise ConfigMgr background and knowledge.  I'm sure it'll be a learning curve for me.

Day 1:
Signed up for Intune 30 day trial, created the first username and password.
It asked me to sign in to, but it wasn't letting me login at first-- had to sign out of my real liveID, and then it told me the This email address is being protected from spambots. You need JavaScript enabled to view it. account didn't exist.
Then I just made a new IE tab; and pasted in -- and without asking for a password, logged me right in.  Seems a little odd; but I suppose that was due to the liveID.

There's an online walkthrough; it told me to create a new group, but any group name I tried said "failed to add group"
Call to b__9f was not permitted with the token|$$|ContextClass=AdHoc|$$|0=b__9f|$$|

Again, not very helpful.  But after much clicking around, found that wasn't the right place to add a group--apparently I need to do that over on; which is then available to be targeted by 'things' in  Seems like a lot of consoles to go to... but if I think of it in my "how does similar stuff work when on premise"--one has a console for AD users and computers, and the CM console, and other consoles--so having multiple consoles to do similar setup for Intune shouldn't surprise me.  Might also be because I *am* standalone testing, and not Azure AD / Hybrid testing.  That would be a different experience and work flow.

Created a test user; and was able to create a group, and explicitly add that test user to that group.
Created a very very basic Configuration policy for Android, and targeted that group.

End of day one... Summary:
Created 30 day trial, created a standard user, created a group with that user, created and deployed a policy to that group.

In attempting to do some Powershell (WinRM) remote actions, specifically using  Roger Zander's Collection Commander, I came across this blog entry and thought "Awesome, already done for me!".

And then I kept getting errors during testing, "Exception calling "Install" : ""  But it would work fine in the home lab... After much head scratching, at work we have a GPO to set Powershell ExecutionPolicy as RemoteSigned--which is good, of course.  But it threw this particular script for a loop.  In the home lab--since it is a home lab--I had set executionpolicy to unrestricted on the test box.

What I ended up doing was I found this blog post about different ways to get around a remote-signed execution policy (in a good way, not trying to do evil things):

The one which was the easiest to implement for these specific needs was the "Bypassing in Script" one detailed here:

I'm sure there are a dozen if not hundreds of blogs posts out there with this exact same information; just posting it mostly for myself.  If it helps someone else, great.  As of late July 2016, these are the versions (and their Marketing or public names) for the ConfigMgr Client.  It doesn't go back to SMS 1.0, or even cm07--so not as useful for "everything ever". 

But if you get "unknown" versions when you run it, you can fill in your own blanks.

SELECT COUNT(resourceID) [Count],
    Client_Version0 [Version]
, case
when client_version0 = '5.00.7711.0000' then 'ConfigMgr 2012 RTM'
when client_version0 = '5.00.7804.1000' then 'ConfigMgr 2012 SP1'
when client_version0 = '5.00.7804.1202' then 'ConfigMgr 2012 SP1 CU1'
when client_version0 = '5.00.7804.1300' then 'ConfigMgr 2012 SP1 CU2'
when client_version0 = '5.00.7804.1400' then 'ConfigMgr 2012 SP1 CU3'
when client_version0 = '5.00.7804.1500' then 'ConfigMgr 2012 SP1 CU4'
when client_version0 = '5.00.7804.1600' then 'ConfigMgr 2012 SP1 CU5'
when client_version0 = '5.00.7958.1000' then 'ConfigMgr 2012 R2'
when client_version0 = '5.00.7958.1060' then 'ConfigMgr 2012 R2 for Linux'
when client_version0 = '5.00.7958.1203' then 'ConfigMgr 2012 R2 CU1'
when client_version0 = '5.00.7958.1254' then 'ConfigMgr 2012 R2 CU1 for Linux'
when client_version0 = '5.00.7958.1303' then 'ConfigMgr 2012 R2 CU2'
when client_version0 = '5.00.7958.1401' then 'ConfigMgr 2012 R2 CU3'
when client_version0 = '5.00.7958.1501' then 'ConfigMgr 2012 R2 CU4'
when client_version0 = '5.00.7958.1604' then 'ConfigMgr 2012 R2 CU5'
when client_version0 = '5.00.8239.1000' then 'ConfigMgr 2012 R2 SP1'
when client_version0 = '5.00.8239.1203' then 'ConfigMgr 2012 R2 SP1 CU1'
when client_version0 = '5.00.8239.1301' then 'ConfigMgr 2012 R2 SP1 CU2'
when client_version0 = '5.00.8239.1403' then 'ConfigMgr 2012 R2 SP1 CU3'
when client_version0 = '5.00.8325.1000' then 'ConfigMgr 1511'
when client_version0 = '5.00.8355.1000' then 'ConfigMgr 1602'
when client_version0 = '5.00.8355.1001' then 'ConfigMgr 1602 with policyagentendpoint.dll update'
when client_version0 = '5.00.8355.1306' then 'ConfigMgr 1602 with KB3155482'
when client_version0 = '5.00.8355.1307' then 'ConfigMgr 1602 with KB3174008'
when client_version0 = '5.00.8412.1000' then 'ConfigMgr 1606 TAP'
when client_version0 = '5.00.8412.1006' then 'ConfigMgr 1606'
when client_version0 = '5.00.8412.1007' then 'ConfigMgr 1606 with KB3180992'
else 'unknown' end as [Marketing Version]
  FROM dbo.v_R_System_Valid
  ORDER BY [Version] desc

there's also this way...if you don't want to deal with all those pesky cumulative updates, or hotfixes

;with cte as (select resourceid, substring(client_version0,6,4) as [Ver] from v_r_system_valid)

select Ver,
when Ver = '7711' then 'ConfigMgr 2012 RTM'
when Ver = '7958' then 'ConfigMgr 2012'
when Ver = '8239' then 'ConfigMgr 2012 R2'
when Ver = '8325' then 'ConfigMgr 1511'
when Ver = '8355' then 'ConfigMgr 1602'
when Ver = '8412' then 'ConfigMgr 1606'
else 'unknown'
 end as [Version]
,Count(resourceid) [Count]
from cte
group by ver
order by ver

Apparently the original article on this from years ago has disappeared; so here's the old info.  This was originally for Config2007; so it may be this won't work, or will have unknown results.  YOU will need to test it and confirm it does what you think you want it to do in your environment.

Reporting on the permissions applied to non-admin shares can also be queried using the attached. Using --> This Zip File <-- , that's a vbscript.  Either deploy it as a traditional old skool package/program/recurring advertisement, or leverage a Configuration Item to deploy that script . Set a recurring schedule for what makes sense in your environment.

To Be Imported into Default Client Settings, Hardware Inventory:

// <:[-<>>>>>>>>>>>Start>>-Share Permissions-<<Start<<<<<<<<<<<>=]:>

#pragma namespace("\\\\.\\root\\cimv2\\sms")
[SMS_Report(TRUE), SMS_Group_Name("Share Permissions"), SMS_Class_ID("SMS_SharePerms")]
class SMS_SharePerms : SMS_Class_Template
[SMS_Report(FALSE), Key] uint32 Counter;
[SMS_Report(TRUE)] boolean Allowed;
[SMS_Report(TRUE)] string ShareName;
[SMS_Report(TRUE)] string Type;
[SMS_Report(TRUE)] string Domain;
[SMS_Report(TRUE)] string TrusteeName;
// <:[-<>>>>>>>>>>>End>>-Share Permissions-<<END<<<<<<<<<<<<<>=]:>

Allowed = True means the Domain/TrusteeName is granted access of Type to the ShareName
Allowed = False means the Domain/TrusteeName is denied access of Type to the ShareName

You'd write reports against the new v_gs_share_permissions0

Currently, the vbscript is limited to 500 share instances. That could be increased by editing line 78, the DIM statements.

By design, share permissions for default shares will not be reported.

Just to be clear, this routine is for Share Permissions: Read, Change, Full. This is not for NTFS permissions on files/folders contained in those shares.

Note that this routine has only had a very brief life so far in a lab environment. There may be unforeseen problems with the script.