If you are like me using MDT 2012 Update 1, and recently decided to update old images with fresh install and latest Microsoft patches, there is a strong chance that you might run into following error during image deployment.
Error is encountered during the processing of unattend.xml, more precisely on IE customization. It appears that IE10 does not support <IEWelcomeMsg> tag and that causes the whole deployment to hang. IEWelcomeMsg tag is present by default in unattend.xml file created by MDT 2012, so the solution is to either upgrade to MDT 2013 which has this issue resolved or to manually remove/comment this line.
You’ll find the unattend.xml file for each sequence under MDTDeploymentShare\Control\%Task Sequence ID%\
Just remove or comment the line like this:
<!-- <IEWelcomeMsg>false</IEWelcomeMsg> -->
My company is using Microsoft Exchange 2010 SP1, there we have a few mailboxes that have permanent out of office assistant set for the purpose of informing people that their message has been received and that we’ll process it ASAP. And that’s fulfilling its purpose, but at some point we realized that the notification is sent only once to each email sender. It doesn’t matter how much time has passed between two sent emails, you would always get out of office reply only for the first message.
This is actually all by design, hard-coded, without the possibility to change or modify this behavior. The Microsoft’s intended purpose for OOF is to notify senders that the recipient is out of office, usually on vacation for some period of time. For that objective, usually there is no need for auto reply with OOF info to be sent out more than once. But for our intents and purposes, this will not do. Those accounts have permanent Auto Reply, and we want our server to respond more than once.
But not too often 🙂 Microsoft left out the possibility to modify OOF settings out of the box for a good reason. If an email server would respond with OOF each time it received an email on that particular mailbox, it could be really easy to either purposely or not cause an email loop. Two mail servers would bounce (auto reply) emails until one of them dies or reaches the mailbox limit. Hence, you should be really careful when meddling with OOF auto reply.
One way I found to make OOF respond more than once is to reset the Auto Reply configuration. Basically, disable it, and enable it right away. The OOF will be sent to each sender again on the first email, at least until the configuration is changed again.
So, one would schedule a PowerShell script to disable/enable OOF on speciefic mailboxes that fit aforementioned intent. Do not reset OOF too often, set the scheduler for an interval of one day at least.
set-MailboxAutoReplyConfiguration -id user.name -AutoReplyState Disabled
set-MailboxAutoReplyConfiguration -id user.name -AutoReplyState Enabled
Few days ago I installed Hyper-V Server 2012, Microsoft’s free virtualization platform and the equivalent of VMware ESXi.
The very first thing that I was stuck with is that Hyper-V Manager available through RSAT doesn’t have an option to mount an ISO or capture a drive from a machine on which is running. Instead it gives you drives of the Hyper-V host, and that would of course require you to have an ISO or the disc itself present on the host.
For most of us this is very inconvenient, we like the ability to mount an ISO from a network share or our machine. One would think, this a Windows box, no problem, i will map a network drive with my ISOs. The mapping would succeed, but mapped drive (letter) will not be visible in Hyper-V manager when trying to mount an ISO. Ok, the next step that the one would consider is mounting from UNC share directly, but that would also fail, with the message “‘VM’ failed to add device ‘Virtual CD/DVD Disk'” & “User account does not have permission required to open attachment”.
The cause of this is that the Hyper-V is intended to run with VMM Library Server and to mount files from it, not any random share. To circumvent this:
- You need to assign full NTFS and share permissions to computer account of Hyper-V on a shared folder with ISO’s you want to mount.
- In AD on the computer account of Hyper-v machine delegate specific service ‘cifs’ to the machine you want your ISO’s mounted from, microsoft calls this constrained delegation.
Here is step by step procedure for the constrained delegation:
- Go to Active Directory Users and Computers
- Find the Hyper-V server computer account and open up its properties.
- Go to Delegation tab.
- Select Trust this computer for delegation to the specified services only radio button.
- Click the Add button.
- Click the Users or Computers… button.
- In the Add Services window, click Users or Computers and enter the computer account that will act as a library server and click OK.
- Select the cifs Service Type and click OK.
The resulting setup should look something like this:
You could reboot the Hyper-V server just for the good measure.
Secure Shell or SSH is a highly versatile application layer network protocol used for secure communication between networked hosts (in Server/client model). Designed as a replacement for telnet with Public-key cryptography for data confidentiality on unsecured networks ie. Internet.
SSH is most popular on Unix like systems and used for remote administration, tunneling, TCP and X11 forwarding and even file transfer (SFTP and SCP). This post will focus on SSH on windows as I mostly work with it, and for me one of the most interesting features – the SSH tunneling / TCP forwarding.
Most popular flavor on POSIX systems is OpenSSH, that includes ssh (the client), sshd (the SSH server daemon), scp, sftp and others.
On Windows: You can actually go with the same OpenSSH package under Cygwin (Unix-like environment for Microsoft Windows).
There are of course some Windows native servers and clients, notable:
KpyM Telnet/SSH Server, freeSSHd, the unbeatable PuTTY and its many forks with my favourite being KiTTY.
DD-WRT and Open-WRT feature Dropbear SSH server and client for its light use of resources.
Local port forwarding
Local port forwarding enables you to tunnel TCP traffic from your machine to ssh server or remote network that ssh server has access to.
SSH client on your local machine listens on specified port and forwards all TCP traffic to the specified destination address and port.
For example: VNC Viewer (with traffic destined to localhost on port 5900 > SSH client listening on port 5900 and forwarding traffic to the specified IP and port on server side of the tunnel -> server -> Other hosts that server has access to (optional).
Note that local port is arbitrary port number as long as you can specifiy it in software that you wish to tunnel.