Windows

  • To enable the administrator (that is disabled by default from Windows 7 onwards):
    net user administrator /active:yes
  • A customer had a requirement for an email in their Office-365-email-hosted organisation to be forwarded to an external email address. They didn't want a mailbox for the email address on their Office 365 subscription. This is what I found to do. 

     

    This was from the Microsoft Office 365 Community Forums (https://community.office365.com/en-us/f/158/t/6767)

     

    1. Create an external contact with the information of the not yet created externally associated account you want the alias to go to.

    Example: Display name="This email address is being protected from spambots. You need JavaScript enabled to view it.; / Alias="fwd-account" / External e-mail adress="This email address is being protected from spambots. You need JavaScript enabled to view it.;

    2. Create a distribution group with the alias being what you want the internal address to be. I used the following settings. (NOTE: I think some of the settings were not available until I saved the initial group and then went back in to edit it)

    a. Add the external account to the membership

    b. Delete your own account from the membership

    c. Under "membership approval" set both the "Closed"

    d. Under "delivery management" set to "Senders inside and outside of my organization"

  • I needed to be able to join a virtual, KVM-hosted Windows Server Std 2008 R2 machine to a CentOS Samba domain with a Centos Directory Server password backend. It took me many hours to get this to work - unfortunately assuming stuff and using OLD information can lead you 'up the garden path'! These are the steps I took :

    1. Install a later version of Samba than is available from the CentOS repos. The latest is 3.4.5 as at 19 January 2010. I downloaded and used this extra repo - ftp://ftp.sernet.de/pub/samba/3.4/centos/5/sernet-samba.repo. Download it to /etc/yum.repos.d. I also like to set enabled=0 in non-standard repo files just so that I use stock RPM's as much as possible.
    2. Then run yum --enablerepo=sernet-samba update samba

    3. Make sure net getlocalsidand net getdomainsid return the same result. See here for more info.

    4. By default samba attempts secure connection to your LDAP server using StartTLS. If you don't have this already setup, turn this off with the ldap ssl = none setting in /etc/samba/smb.conf.  If you don't then the join will not work - An 'Access is Denied' message will appear when you attempt to join. Once you have joining working, and you haven't already, then setup up secure connections between Samba and LDAP.

    5. *** THIS IS IMPORTANT *** Check, re-check and re-check again the /etc/ldap.conf, /etc/smbldap-tools/smbldap_bind.conf and /etc/smbldap-tools/smbldap.conf config files. These make or break your samba/LDAP setup. Make sure the base dn is correct, the directory manager binddn and binddnpasswd is correct. Make sure the nss_base settings are correct. Make sure the three files are consistent with each other. Then go and check again!!!!

    4. In the Windows Registry set/add the following keys. The bottom two are set the way shown by default but some sources on the internet suggest to turn them off - IF you do then the join will happen but you won't be able to login with a domain user - an error about "The trust relationship between this workstation and the primary domain failed" will occur. DO NOT TURN THESE OFF:


    [HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters]
    DomainCompatibilityMode=dword:00000001
    DNSNameResolutionRequired=dword:00000000

    [HKLM\SYSTEM\CurrentControlSet\services\Netlogon\Parameters]
    RequireStrongKey=dword:00000001
    RequireSignOrSeal=dword:00000001

     


    5. I also changed the Local Security Policy of the joining Windows workstation, under Security Options. I set "Network Security: LAN Manager authentication level" to "Send LM & NTLM - use NTLMv2 session security if negotiated"

    Helpful Sites
    Samba's Wiki Page re Windows 7: http://wiki.samba.org/index.php/Windows7
    Checking SID's are the same: http://blog.kenichimaehashi.com/?article=12600130160
  • Recent KB4480970, KB4480968 updates for Windows 7, 2008 r2 server are breaking access to SMBv2 shares.

    The fix is a registry entry (run in 'cmd' as administrator):

    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

    The effect is immediate - no reboot required.
     
    Alternatively, install this later Microsoft Update (KB4487345) to fix the problem:
     
  • Ever felt the need to change the location of the SFC log file? Well you can using an environment variable. This is particurlarly useful when in the Windows Recovery Console. Set the following environment variable before running SFC:

     

    SET WINDOWS_TRACING_LOGFILE=D:\CBS.LOG
    SFC /SCANNOW /OFFBOOTDIR=D:\ /OFFWINDIR=D:\WINDOWS
  • This is a regurgitation of an articleon Implbits website:

     

    Use the following command to reset the trust relationship between a workstation and it's primary domain:

     

    netdom.exe resetpwd /s:<server> /ud:<user> /pd:*

     

    <server> = a domain controller in the joined domain

    <user> = DOMAIN\User format with rights to change the computer password

     

     

    Here are the full steps:

    You need to be able to get onto the machine. I normally just log in with the local Administrator account by typing, ".\Administrator" in the logon window. I hope you remember the password. If you’re creative and resourceful you can hack your way in without the password. Another option is to unplug the machine from the network and log in with domain user. You will be able to do disconnected authentication, but in the case of a reset machine, remember that you may have to use an old password. Your domain user’s cached credential has the same problem as the machine’s private secret.
    You need to make sure you have netdom.exe. Where you get netdom.exe depends on what version of Windows you’re running. Windows Server 2008 and Windows Server 2008 R2 ship with netdom.exe you just have to enable the Active Directory Domain Services role. On Windows Vista and Windows 7 you can get it from the Remote Server Administration Tools (RSAT). Google can help you get them. For other platforms see this link: http://technet.microsoft.com/en-us/library/ee649281(WS.10).aspx"

     

    Extra steps if the machine is a domain controller:

    If the broken machine is a domain controller it is a little bit more complicated, but still possible to fix the problem.

    I haven’t done this for a while, but I think this works:
    Turn off the Kerberos Key Distribution Center service. You can do this in the Services MMC snap-in. Set the startup type to Manual. Reboot.
    Remove the Kerberos ticket cache. A reboot will do this for you, or you can remove them using KerbTray.exe. You can get that tool here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17657
    Post change steps. Do these in conjunction with 5 below. Turn the Kerberos Key Distribution Center Service back on before rebooting. You should reboot the domain controller and then force replication in the Active Directory Sites and Services MMC snap-in.
    Run netdom.exe to change the password.
    Open an administrative command prompt. On Windows platforms with UAC enabled, you will need to right-click on cmd.exe and select "run as Administrator".
    Type the following command: netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
    Reboot the machine.


    Here is more information on netdom.exe: http://support.microsoft.com/kb/325850

  • It can be confusing when you go to log into a computer on your domain and you’re suddenly confronted with the message:

    The trust relationship between this workstation and the primary domain failed.

    Why would you get this message? Typically it happens when the computer you’re trying to log into has had it’s Active Directory account deleted (generally by accident). The Computer account on the Active Directory server has a special key that is generated for authentication reasons and it can’t be recovered if you’re not running a later version of Active Directory with undelete functions turned on.

     

    Unjoin and Rejoin the Domain?
    Administrators can get a bit worried when this happens because the usual solution is to unjoin the computer from the domain and then rejoin it. This can result in having users have to create new profiles and other problems that are at a minimum annoying. Thankfully, I can tell you NO, don’t unjoin and rejoin the domain!

     

    Powershell is your Friend
    Yes, as odd as it has been, Microsoft has seen the light of the command line world and given us Powershell. If you’re running Powershell v3 or later, you can solve your missing computer Active Directory account very simply. Just do the following:

    Make sure that you have PowerShell v3 installed. If you’re running Windows 7, like this computer was, you’ll need to do 2 steps to upgrade to PowerShell 3. Follow these steps for Installing Windows PowerShell and follow the steps in the section referencing the appropriate Windows version. If you have problems with this, feel free to leave a comment and I’ll do my best to help.
    Create the computer account in Active Directory. If the Active Directory computer account exists already, you can skip this step.
    After you have PowerShell 3 installed, run the following command on your untrusted computer:

    $PSCredential = Get-Credential
    Reset-ComputerMachinePassword -Server -Credential $PSCredential


    Once you enter your credentials and the command has completed, your computer should once again be connected to Active Directory and able to authenticate.

    Source: https://www.prolved.com/trust-relationship-workstation-primary-domain-failed/

  • I had a situation where adding an Office 365 account to Outlook 2016 would produce the following window when asking for the user credentials:
    windows security empty window
    i.e. No entry fields for the login or password - huh?!?!?!
     
    After weeks of googling, letting it sit for a while, more googling, letting it sit for a while, even more googling I stumbled upon a Microsoft Technet forum page that hinted at the C:\ProgramData\Microsoft\User Account Pictures\user.bmp file not being to Windows liking. This rang a bell since as part of my setting up the customers Windows 7 DVD image for install I had made a custom user tile.
     
    Once I had opened the user.bmp in MS Paint and resaved (as a 24-bit Windows Bitmap File) all was good! I retried the Outlook 2016 Office 365 and BOOM! the User Tile, Login Name and Password all displayed, waiting for entry.