Step by Step Directions for Techs
April 30, 2017Posted by on
I keep running into this so I thought I would put it up here.
If you have a customer without on-premise Active Directory and they use Office 365, you can leverage that with Windows 10. It is a bit cumbersome for some things, like adding users to the admin group. Here is a workaround:
- Login as the AzureAD / Office 365 user you want to be a local admin. This introduces that user’s GUID to the system.
- Log out and login as a local admin user.
- Open a command prompt as Administrator and use this command, replacing the username:
net localgroup administrators AzureAD\JohnSmith /add
Regarding the user name: It isn’t the name they login in with. This is the display name all run together. For example, if they are listed as “Bill Jones” in the directory and they login as “bill_jones”, it would be “BillJones”. If they are listed in the directory as “William Jones” (again the display name) but login as “bill_jones”, it would be “WilliamJones”.
March 29, 2017Posted by on
I spend a lot of time trying to automate my life. Some of it is work, but a lot of it is personal. Most of it is trivial.
Somewhere I read about a guy that writes scripts to do anything at work that takes more than 15 minutes. Basically, he was automating his job. After reading that I decided to start doing the same thing. However, it involves my home life too. Turning off (or on) lights, dealing with schedules, computer maintenance, and things like that. So this will be a bit of everything.
I am adding a section that just concerns what I have found works. In some cases, there will be some source code I post on GitHub and link here.
March 27, 2017Posted by on
I know there have to be thousands of these articles, but I can never find the information when I need it. So here it is:
Get-MSOLUser -UserPrincipalName | Select PasswordNeverExpires
You need a couple things (from https://technet.microsoft.com/library/dn975125.aspx):
These steps are required once on your computer, not every time you connect. However, you’ll likely need to install newer versions of the software periodically.
1. Install the 64-bit version of the Microsoft Online Services Sign-in Assistant: Microsoft Online Services Sign-in Assistant for IT Professionals RTW.
2.Install the 64-bit version of the Windows Azure Active Directory Module for Windows PowerShell: Windows Azure Active Directory Module for Windows PowerShell (64-bit version).
March 11, 2014Posted by on
Trying to get into a customer’s Citrix environment and I couldn’t get the plugins to load in Internet Explorer. The install started and then shut down with no errors. The plugins weren’t installed and the site said that they weren’t detected.
Thinking it was the UAC, I downloaded the plugins and ran with elevated rights. This time I received an error:
To clear this error, you need to remove the key “HKEY_CURRENT_USER\Software\Citrix” from the registry. As always, I suggest that you export the key before deleting it. Also, if you have any other Citrix products installed, this may impact those as well.
Now, get to work!
January 20, 2014Posted by on
I have found that when testing MDT deployments, I end up with a lot of USB drives and people asking for them to be updated. Inevitably, someone uses an old one to image and the complaints come rolling in.
This is a simple script that creates a file with a name that is a time stamp. That way, I know when I created the media.
For /F “tokens=2-4 delims=/ ” %%a in (“%DATE%”) DO SET MDY=%%a%%b%%c
FOR /F “tokens=1,2 delims=:” %%d in (“%TIME%”) DO SET ORAS=%%d%%e
REM output to file
echo TimeStampFile > \\servername\sharename\%MDY%_%ORAS%.txt
I save the file to the share that MDT copies the media to. That is done in the last time with \\servername\sharename. It produces a TXT file with the date and time in it. Right now it is Jan 20th, 2014 at 10:23 AM. The file name is 01202014_1023.txt.
Works great. Less filling.
December 17, 2013Posted by on
It isn’t hard, but you have to do a few things to prep a USB drive for use in imaging with MDT. You need to mark the partition as active and you need to make sure it is formatted for NTFS.
- Plug in the USB drive.
- Click Start | Run
- Type “CMD”
- Press “OK”
- Type “diskpart” into the command prompt and press the enter key
- Type “list disk” and press the enter key. This will list the available drives
- Determine which disk number is your USB drive (you can frequently tell by size). If you are unable to determine it, unplug the drive and list the disks again to see which one is missing. Plug it back in and list them again. You should be able to figure it out by the differences.
- Type “select disk 1” (or whatever your disk was as determined above) and press the enter key.
- Type “list partition” and press the enter key to list the partions.
- Type “select partition 1” and press the enter key
- Type “active” and press the enter key
Here is the output from my window:
You then need to format the drive as NTFS. You can do it here by:
- Type “format fs=ntfs QUICK” and press the enter key inside of diskpart.
- You can do it through disk manager and do a quick format.
Type “Exit” to leave the DISKPART tool.
Now, you just need to copy the contents of your MDT content folder to the drive and you are set! Don’t forget to boot off of it (by setting the BIOS or choosing an alternative boot device).
If you are using a SANDisk, you may need to do one more thing. You need to get a copy of BOOTSEC (available in WAIK). Open a command prompt and execute “Bootsect.exe /nt60 D:” (where D: is your USB drive) from the directory you put BOOTSEC into.
December 11, 2013Posted by on
Never fear, a script is here (kinda).
Recently I was working to automate the installation of a poorly written program. For the life of me this thing would not install quietly. Repackaging it failed and I was running out of time. I choose to install the program and pass the appropriate keystrokes to it.
Note: This is not advised when rolling applications out if the user is at the keyboard. One click to another application and this all goes haywire.
So what I did what create an install.vbs script that looks a bit like this:
Set objShell = WScript.CreateObject(“WScript.Shell”)
‘This pulls up the “Setup” window as the active window
Do Until Success = True
Success = objShell.AppActivate(“Setup”)
‘Takes a bit before the application can take inputs. This is 6 seconds
‘This clicks the install button
‘It takes a little bit to install it
‘Close configuration window by pressing Alt-D-E
Once you have that, you launch the setup program (you can do that in this script or in another one. However, if you do it from a batch file, you need to use a start command (otherwise it waits for the process to finish before moving on):
start “” “%~dp0setup.exe”
start “” “%~dp0install.vbs”
Note: The %~dpo is a shortcut that uses the current directory it is being run out of instead of hard coding the paths.
As you can see, there is a bit of timing you have to get down. That is just trial and error. I used a virtual environment and snapshots to get the it working so I could always install on a “clean” system.
If there are other keystrokes you need, here is where I got them:
October 28, 2013Posted by on
For as simple as the software seems to be, there are some things to watch out for:
- Disable password expiration for the DirSync service account. If you don’t do this, the service will stop working in 90 days until you reset the password on the portal and reconfigure DirSync.
- Import-Module msonline
- $cred = Get-Credential
This will prompt you for credentials for an admin account. You can use the DirSync account.
- Connect-MsolService -cred $cred
- Set-MsolUser -UserPrincipalName email@example.com -PasswordNeverExpires $true
- DirSync does not automatically assign licenses to the accounts it copies.
- This article will show you how to sync licenses – https://stepbytech.wordpress.com/2013/10/24/how-to-automatically-assign-licenses-in-office-365/
- Initiating a Full Sync in DirSync does NOT initiate a full password sync.
- Open “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1”
- Run “Set-FullPasswordSync”
- If you want to do a quick sync for accounts, don’t do it from miisclient. Do it from PowerShell.
- Open “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1”
- Run “Start-OnlineCoexistenceSync”
- DirSync only allows for 15,000 accounts to be sync’d unless you call Microsoft first. This includes containers, groups, and users. If you hit this limit, you can filter what goes up to Azure.
October 24, 2013Posted by on
Well, you can’t. Have a great day!
Aside from this being super helpful, I have a workaround for you based on this post from Microsoft (it has a few minor errors) – http://social.technet.microsoft.com/wiki/contents/articles/15905.how-to-use-powershell-to-automatically-assign-licenses-to-your-office-365-users.aspx
This file (rename it to ZIP) has the Powershell files: O365LicenseScripts
This assumes that you have the MS Online Services Sign-In Assistant (you already have this if DirSync is installed) and Microsoft Online Services Module for PowerShell (found here http://g.microsoftonline.com/0BX10EN/423).
How to get it working:
- Unzip the files to C:\O365LicenseScripts (or where you keep your scripts). You can also recreate the scripts from the MSFT post, but there are a few issues with spaces, file names, and it doesn’t set a location for the users before assigning the license.
- Open Powershell
- CD to C:\O365LicenseScripts
- Run .\SetupScript.ps1
- [Office 365 directory sync account – using the onmicrosoft.com address]
- [Password for account]
This is the attribute in AD you are using to identify which users get licenses
Value that the users will have if in AD they are supposed to have the license
The attribute in AD that has the license name, like OFFICESUBSCRIPTION for Office.
- This will create several scripts from the TMP files and some text files.
If you run Get-LicensingInputFromAD.ps1, you will see what the system thinks the users should be and their corresponding licenses.
If you run AssignLicense.ps1, it will assign the licenses based on what the Get-LicensingInputFromAD.ps1 script output was (stored in the queuedLicense folder created during setup).
If you want to schedule it, you can use the Schedule.ps1 script. I won’t go too far into the weeds, but the command is “powershell.exe” (without the quotes) and the arguement is “-file C:\O365LicenseScripts\Schedule.ps1” (without the quotes).
There is one difference in my scripts. You will find 2 lines that are commented out in case you don’t want to set the license type in Active Directory. I often find that most customers only use one license type, so I put in an attribute to say which accounts get the license and then hard set the license in the script (set it in the TMP file otherwise the setup script will delete your work!).
October 23, 2013Posted by on
Who really wants to see all those pesky accounts and groups up in Office 365? Not me (and probably not you if you are reading this). I want to see accounts that I need to give licenses to.
Disclaimer – you can really mess up Office 365. Be careful!
- In Windows Explorer, navigate to “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell7”.
- Double click miisclient.exe to open this window
- Click on “Management Agents” on the toolbar.
- This is where the magic happens. Right click the “Active Directory” agent and choose properties.
- Select “Configure Connector Filter”.
- Select “user” by scrolling down in the right pane to view the filters for this object.
- Add your filters!
These filters are for things you don’t want. As you can see in the image above, I am filtering for users that DO NOT contain “365” in the ExtensionAttribute15 (you can edit that in Active Directory). By using this, I will only get users that have it. Consider it a “negative filter”.
Now, before you work on this too long, let me give you some hints:
- You can’t filter users based on their group membership. It has to be an attribute that is in their user account (think about what you can see in Active Directory).
- You cannot see attributes that you put in by extending the schema, so you can’t filter on those either.
- If you don’t want to sync other objects, like groups, don’t uncheck the object types or delete the joins or anything else like that. It breaks the sync with Office 365. Instead filter all the objects out by choosing something that you know every object has. In this situation, I didn’t want to replicate the groups to O365, so I filtered for every group object that had a GUID:
- If you really mess something up, delete the Azure agent and the AD agent and re-run the DirSync configuration. It will recreate the agents in their vanilla form. If you messed up Office 365, this may or may not fix it.
That should get you going. Good luck!