• Mike Rodrick

    Hey @Adam-Tyler ,

    The correct answer would be D.

    Your process of elimination is spot on.

    A) The Set-DAClient cmdlet is used to configure Force tunneling, support for down-level clients, and support for remote computers only

    B) Set-DirectAccess is not a valid cmdlet.

    C) The security group named 'Windows Authorization Access Group' is used to grant access to the tokenGroupsGlobalAndUniversal attribute on User objects. You can see this attribute on the properties of a user account if you enable advanced view, go to the attribute editor tab, and change the filter to include constructed attributes. Enterprise domain controllers are members of this group.

    D) The 'Direct Access Client Settings' GPO is one of two GPOs created when you deploy DirectAccess, This policy sets the configuration for DirectAccess clients. Settings like firewall rules, NRPT settings, connection security settings, and more. It is linked to the domain, and then security filtering is used to determine who can apply the policy.

    So your logic is correct. To limit the DirectAccess trial to LAB\Test Computers, they would have used security filtering. The DirectAccess deployment wizard has a step where you chose 'one or more security groups that contain client computers that will be enabled for DirectAccess'. They would have removed the security group 'LAB\Domain Computers' (the default), and added the security group 'LAB\Test Computers'. Now that the trial is over, that needs to be changed. You can edit this setting in the Remote Access Management console, or you can edit the security filtering directly on the GPO in the Group Policy Management console.

    posted in Microsoft read more
  • Mike Rodrick

    @bedrock1977

    Sorry Chris, forgot to mention the script I wrote is a PowerShell script. You will need to save it as a .ps1 file. It does not have to be in the same folder as the files, it can be saved anywhere.

    You will need to change the ".txt" to ".mp4" in $sourcePath

    $files = Get-Content D:\list.txt
    foreach ($file in $files) {
        $sourcePath = "d:\source\" + $file + ".mp4"
        $destinationPath = "d:\destination\"
        Move-Item $sourcePath $destinationPath
    }
    

    Also remember, you cannot double-click a PowerShell script to run it. You will need to open PowerShell and call the script by typing in the path to the script. For example, if you saved the script as MoveFiles.ps1 in a folder on your c drive called scripts, open PowerShell and type

    C:\scripts\MoveFiles.ps1
    

    Let me know if this works for you.

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Bedrock1977 ,

    Try something like this...

    $files = Get-Content D:\list.txt
    foreach ($file in $files) {
        $sourcePath = "d:\source\" + $file + ".txt"
        $destinationPath = "d:\destination\"
        Move-Item $sourcePath $destinationPath
    }
    

    Modify $files to point to your text file with the list of filenames.

    $files will be an array of names from the source file.

    Then you will loop through the array, dynamically building the source path of the file to
    be moved. I assumed all the files were .txt files, so it adds .txt to the end of the name.

    Modify $sourcePath by replacing "d:\source" with the current location of the files to be moved. (Including the trailing )

    Modify $destination by replacing "d:\destination" with the location you want to move the files to. (Including the trailing )

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Bedrock1977 ,

    Do all of the files that you want to move have the same file extension? What is it?

    posted in Microsoft read more
  • Mike Rodrick

    Hello @Waqkas-Ahmed

    Maybe something like this? Uncomment the appropriate section at the end of the script depending if you want to set the password to something you know, or have the user change the password at next logon.

    $ErrorActionPreference = 'Stop'
    $VerbosePreference = 'Continue'
    
    #User to reset password for
    $UserName = Read-Host "Enter username"
    $UserAccount = $null
    
    Try {
        Write-Verbose "Retrieving $UserName"
        $UserAccount = Get-LocalUser $UserName
        Write-Verbose "User $UserName found"
    }
    
    Catch [Microsoft.PowerShell.Commands.UserNotFoundException] {
        "User $UserName was not found" | Write-Warning
    }
    
    Catch {
        "An unspecified error occured" | Write-Error
        Exit
    }
    
    If ($UserAccount) {
        # To force a local user to reset password on next logon
            # net user $UserName /logonpasswordchg:yes
            # Write-Verbose "User will have to change password at next logon"
    
        # To reset a local users password to a known value
            # $NewPassword = Read-Host "Enter new password" -AsSecureString
            # $UserAccount | Set-LocalUser -Password $NewPassword
            # Write-Verbose "Password for $UserName was reset"
    }
    

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Adam-Tyler ,

    A root CA is almost always configured as an offline, stand-alone CA for security reasons. If the root CA is compromised, the entire CA infrastructure is compromised. All issued certificates have to be revoked, and the CA infrastructure rebuilt from the top.

    So your understanding is correct, the offline stand-alone root CA cannot be used for auto-enrollment. But this is ok, as the root CA is only used to issue certificates to the first level of subordinate CAs. After the subCA certificates are issued, the root is taken offline.

    So for your questions,

    1. Because the root CA will be offline, it should not be configured on a domain member. By default, computers change their password every 30 days, and if the root is kept offline for longer than this, trust issues will occur. Because the root CA doesn't issue certificates to users or computers, there is no need to store any information in Active Directory, so it should be configured as stand-alone, not enterprise.

    2. Because the root CA is offline, and stand-alone, they usually fall outside of update policies. They can be brought online occasionally to apply updates if you have to, but they are powered off, so little chance for compromise. Depending on your CRL lifetime, the root CA might only be brought online once a year. So when you do bring it online, plan accordingly, there will be a few updates ;)

    3. Yes! This is the best practice for a CA hierarchy. The offline, stand-alone root CA is configured first. Then, enterprise subordinate CAs are configured, and request subCA certificate from the root. Once they are configured, the root is taken offline. The subordinates are enterprise CAs, so they store their information in Active Directory, and support auto-enrollment for users and computers.

    4. Not that I'm aware of. I have used a single-tier hierarchy in test labs, where my root CA was also my issuing CA, but never in production. The root CA is always stand-alone and offline. The root CA isn't used to issue certificates, other than to subordinate CAs.

    Hope this clears things up! Coincidentally, I am shooting shows on this very topic this week. If you get a chance, join us in the chat room in the afternoons!

    posted in Microsoft read more
  • Mike Rodrick

    @Waqkas-Ahmed ,

    What are you trying to do with the If ($existing -eq $null) statement? In this script, I believe it will always be null, since the variable $existing is never set to anything.

    Also, the account is created, or fails, when you run the New-LocalUser cmdlet
    $Account = New-LocalUser -Name $TrimmedUserName
    before the if statement is run. We would need to move this command inside the if statement.

    We can use the Get-LocalUser cmdlet to test if a username exists. Then we can use that boolean to control our if statement. Something like this

    $NewLocalUserName = Read-Host -Prompt "Enter a name for the new user"
    $TrimmedUserName = $NewLocalUsername.TrimEnd()
    $group1 = "Power Users"
    $group2 = "Remote Desktop Users"
    # $Password
    $exists = Get-LocalUser -Name $TrimmedUserName -ErrorAction SilentlyContinue
    
    if (!$exists) {
        $Account = New-LocalUser -Name $TrimmedUserName
        Write-Host "Creating new local user $Account. `n"
        Write-Host "Adding $Account to the $group1 group."
        net localgroup "Power Users" "$Account" /add
        Write-Host "Adding $Account to the $group2 group."
        net localgroup "Remote Desktop Users" "$Account" /add
        Write-Host "Ensuring password for $Account never expires."
        WMIC USERACCOUNT WHERE "Name='$Account'" SET PasswordExpires=FALSE
    }
    else {
        Write-Host "Username already exists"
       # Write-Host "Setting password for existing local user $Username."
       # $existing.SetPassword($Password)
    }
    
    

    posted in Microsoft read more
  • Mike Rodrick

    Hey @Waqkas-Ahmed ,

    One solution would be to prompt them for the name first. Then you can trim the name before you pass it to the New-LocalUser cmdlet.

    $NewLocalUserName = Read-Host -Prompt "Enter a name for the new user"
    $TrimmedUserName = $NewLocalUsername.TrimEnd()
    
    
    $Account = New-LocalUser -Name $TrimmedUserName
    
    $Password
    
    if ($existing -eq $null) {
    Write-Host "Creating new local user $Account."
    
    Write-Host "Adding local user $Username to $group."
    & net localgroup "Power Users" "$Account" /add
    & net localgroup "Remote Desktop Users" "$Account" /add
    }
    else {
    Write-Host "Setting password for existing local user $Username."
    $existing.SetPassword($Password)
    }
    Write-Host "Ensuring password for $Account never expires."
    & WMIC USERACCOUNT WHERE "Name='$Account'" SET PasswordExpires=FALSE
    

    I'm not sure what you are trying to do with the password. Since you are not providing a password when running New-LocalUser, it is prompting them to enter a password. It is stored as a secure string, which doesn't have a trim method. You want them to change it again?

    Let me know and we can fix that too. Hope this helps.

    posted in Microsoft read more
  • Mike Rodrick

    @Waqkas-Ahmed

    I'm not the Exchange guy, but I will try to find some time to set up a test lab and see what I can do. In the meantime, take a look at these cmdlets to get you started:

    For an on-premise Exchange Server
    Get-MessageTrackingLog -Recipients mike@itpro.tv

    For Exchange Online
    Get-MessageTrace -RecipientAddress mike@itpro.tv

    posted in Microsoft read more