제2의 비엔지니어 인생관을 꿈꾸며

Filed under Study

An internal email distribution group set with an external email address is not able to receive emails from external users. You do not receive Non-Delivery Reports (NDR) as well. This issue is seen on both Microsoft® Exchange Server® 2007 and 2010 versions. 


The email distribution groups are configured to require sender authentication by default. When it comes to messages from external sources, it is not possible to authenticate the sender. To successfully send messages externally, you need to disable the mandatory authentication of senders.   

To enable the email distribution group to receive emails from external sources, follow the procedure below:
1.Log on to the Exchange Server as an administrator user.
2.Click Start, All Programs, Microsoft Exchange Server 2007, Exchange Management Console.
3.In the Exchange Management Console window, on the left-hand pane, browse to Recipient Configuration, Distribution Group.
4.Select the email distribution group from the middle pane and click Properties in the right-hand pane.
5.In the email distribution group Properties window, select the Mail Flow Settings tab. For example, the image below shows the Properties window of the email distribution group 'AA Sales'.
6.Select Message Delivery Restrictions and click the Properties... button on the top. 
Email Distribution Group Properties

사용자 삽입 이미지

7.In the Message Delivery Restrictions window, uncheck the 'Require that all senders are authenticated' check box.
Disable the sender authentication

사용자 삽입 이미지

8.Click OK, Apply and OK again. The email distribution group will now be able to receive emails from the external sources.
9.By default, all email distribution groups are set to authenticate the senders, so the procedure above needs to be applied to all email distribution groups that need to receive externally sent emails.

Note: The procedure above is also applicable for Exchange Server 2010.
그룹메일이 자꾸 라우팅 실패가 떨어지면서 SMTP 송수신이 문제인가 한참을 찾았습니다. 외부에서 개인메일 전부 송수신되고 내부에서도 그룹메일 전부 송수신이 되는데 유일하게 외부에서 그룹메일로 보내면 인증안되었다고 트래킹로그에 남더랍니다. 2013 만쓰고 있어서 2010이 긴가민가만 생각이 들고 이런경우 혹시나 싶어서 포스팅 남깁니다.

역시나 구글신~!!!

2017/03/01 23:49 2017/03/01 23:49
Filed under Study

http://www.cievo.sk/2013/04/13/exchang ··· omain%2F

We had Active Directory domain called DOMAIN.LOCAL. There was Exchange 2010 installed. It was fully functional. After some time I added new sub-domain/child domain SUB.DOMAIN.LOCAL and migrated users with mailboxes from DOMAIN.LOCAL to SUB.DOMAIN.LOCAL.

사용자 삽입 이미지

Error stated: Exception message: Could not find any available Domain Controller in domain DC … so problem is probably in the way Exchange locates domain controllers. When users clicked F5 or refreshed website, he could see his e-mails normally.


There was also event 2130 logged on Exchange server saying Exchange Active Directory Provider could not find an available domain controller in the domain.




When you want to install Exchange into Active Directory domain, you need to prepare forest and also domain before you install it. You use setup.com (from installation DVD of Exchange) with some switches (for example /PrepareSchema, /PrepareAD,…). So new added domain SUB.DOMAIN.LOCAL to existing AD Forest was not prepared for Exchange implementation. I ran following command setup.com /PrepareDomain:SUB.DOMAIN.LOCAL:

사용자 삽입 이미지

If you have more then one domain to prepare for Exchange, you can use command setup.com /PrepareAllDomains.


The best way to run /PrepareDomain or /PrepareAllDomains is:


  • to be logged domain controller with role Schema Admin
  • to be member of Enterprise Admins group
  • to be member of Schema Admins group

I hope you will not make same mistake as I did

트리도메인에 익스체인지 설치할때 엄청난 삽질을 하다보다 이글보고 겨우 해결된 케이스였습니다.
2013 다르고 2010 다르다보니 많이 어지럽기도 하고 트리도메인 만들때부터 단번에 설치되는 케이스가 한번도 없었습니다. 자식도메인 별무리가 없었는데 트리도메인은 정말 어지럽더군요.

2017/02/19 03:00 2017/02/19 03:00
Filed under Study

sudo apt-get update –fix-missing


sudo dpkg –configure -a


sudo apt-get install -f

the problem of a broken package still exist the solution is to edit the dpkg status file manually.


  1. $ sudo nano /var/lib/dpkg/status    (you can use vim or gedit instead of nano)
  2. Locate the corrupt package, and remove the whole block of information about it and save the file.


Unlock the dpkg – (message /var/lib/dpkg/lock)

sudo fuser -vki /var/lib/dpkg/lock

sudo dpkg –configure -a


For 12.04 and newer:

You can delete the lock file with the following command:

sudo rm /var/lib/apt/lists/lock

You may also need to delete the lock file in the cache directory

sudo rm /var/cache/apt/archives/lock

2017/02/03 15:42 2017/02/03 15:42
Filed under Life Story

그의 이야기를 잘들어보면 뭐가 문제인지를 보여주는데 이놈의 기자들은 무슨관점으로 기사를 써데서 사람 헷갈리게 하는지...
그나라 이야기가 왠지 옛날 우리나라의 데쟈뷰 현상을 보는듯한 기분이 들정도입니다.

2017/01/25 01:44 2017/01/25 01:44
Filed under Study


psexec \\REMOTE_SERVER_NAME shutdown /r /t 01

alternatively you could use:

shutdown /m \\REMOTE_SERVERNAME /r /t 01

This returned the following error:

1115 A system shutdown is in progress

This basically meant that a system shutdown was already in progress,  and therefore the command was unable to force a reboot. In the end I used the pskill command to stop the winlogon service on the remote server to try and release whichever process wass causing the server to hang on shutdown. I should stress that this was a last resort, and not something that I would recommend doing unless essential:

pskill \\REMOTE_SERVER_NAME  winlogon

Anyway, after another few minutes the remote server did finally restart, although there are a few other things that I should mention that happened in the process. The operating system on this machine was Windows Server 2008 R2. After the server came back up (verified by ping -t REMOTE_SERVER_NAME) I tried to RDP the box again. I was able to enter my credentials and the logon process appeared to start, but after a few seconds the following message appeared on the screen:

Please wait for the Windows Modules Installer

The machine sat like that for quite some time, and then started ‘Configuring Updates’. My RDP session then abruptly ended and the server restarted itself again. Again, when it was back up I tried to RDP the server again and received the ‘Please wait for the windows modules installer message’ for a second time. Thankfully, after a few minutes and another ‘configuring updates’ message, logon continued and ther server was back up and running. On checking the event log and windows update log I was able to verify that all the updates had installed OK, and there were no other errors worthy of note. So in summary, if you want to save yourself a long trip, to most likely press a power or reset switch, you may want to try the above first.   

위사항에는 전제조건이 RPC를 허용한 같은 서브넷이나 네트워크 상에 있어야 되는것이 문제입니다. IDC나 원격지 서버에는 독립서버인 하나만 존재하지 않기에 옆에 서버들이 있는게 대부분입니다. 필자는 클러스터환경에서 행이 발생하니 수많은 가상화 서버가 존재하는데서는 난처할수밖에 없었습니다. 종료중이라고만 나오고 핑은 안끊어지고 터미널도 안붙고 파워쉘로 붙어서 shutdown -r 명령어도 종료중이라고만 나오고...
가상화 서버라면 재시작이나 종료버튼만 누르면 넘어가겠지만 물리서버인 경우는 직접 파워버튼이나 리셋버튼을 누르지 않는한 해결방법이 없었습니다. 운영근무자한테 리셋눌러주세요도 좋은 방법이겠지만 운영근무자가 없는 환경이거나 그누가 서버의 환경을 아는 사람이 없다면 파워버튼 눌러주기도 쉽지 않은게 현실입니다.
그래도 윈도우 서버가 파워쉘이라는 네트워크 우선순위 서비스란걸 만들어줘서 다행인지도 모릅니다. 다른 서비스들이 다 중지되도 리부팅하기 직전까지는 핑만 살아있는 환경에서는 최소한 파워쉘까지는 붙습니다. 무슨수를 써도 강제종료가 안되면 강제 블루스크린이라도 발생하고 싶은게 간절하기도 해도 잔머리를 굴려봤습니다.
윈도우의 중요한 커널과 연동되는 서비스나 프로세스를 강제로 죽여버리면 블루스크린이 뜰까? 해서 중요한 프로세스를 생각해봤습니다. 제일 먼저 생각나는 프로세스가 svchost.exe 프로세스입니다. 저프로세스에는 여러가지 서비스가 종속되어 있습니다. 네트워크부터 RPC 기타서비스의 통합 프로세스입니다. 2000년대 초반때 XP시절 RPC 취약점으로 인한 바이러스 공격때문에 우리나라 전체 윈도우 사용자들이 부팅만 되면 1분후에 리부팅되는 난리를 겪은적이 있었습니다. 그래서 필자는 일단 저 중요한걸 죽여보자 해서 날렸습니다.
taskkill /f /im svchost.exe 를 날렸더니 네트워크만 끊어지고 아무런 반응이 없는겁니다. 아 결국은 블루스크린도 안나고 강제종료 버튼누르러 기계실까지 차타고 가야되나를 고민하고 멍하던 순간에 다시 핑이 올라오네요 ㅋㅋㅋ.
혹시나 싶어서 가상화 윈도우에 명령어 날려봤습니다. 5분후에 그냥 리붓되는것처럼 다시 부팅이 되는겁니다. 보통 강제로 죽이거나 하면 비정상 종료라고 이벤트라도 올라오는데 정상적인 리부팅처럼 진행되었습니다. 이벤트를 봐보니 역시나 예상했던데로 svchost 프로세스에 power 서비스가 종속이 되어 있는걸 보여주고 있습니다.

사용자 삽입 이미지
그렇다면 Power 서비스만 죽이면 리붓이 이루어지는건데 svchost.exe -k DcomLaunch 프로세스만  종료하면 됩니다. 이걸 찾는 방법은 tasklist /svc 를 실행하면 위 동일한 프로세스지만 각각 서비스가 다른 설명이 보입니다. 그러면 해당 PID값으로 강제종료를 진행합니다.
taskkill /f PID
어찌보면 강제종료하면서 파일서버나 중요한 데이터가 있는 서버가 데이터 크래쉬 나는걸 방지하기 위해선 이런 긴급 리부팅 명령을 진행하는게 오히려 좋은 방법이 아닐까 생각해봅니다.
특히 윈도우 업데이트를 진행할때 강제 리부팅이 되어버리면 업데이트 DB가 깨져서 다음부터는 윈도우 업데이트도 안되고 역할 및 기능서비스 추가삭제도 안되고 포맷까지 하는 상황까지 오게됩니다.
서버콘솔에서도 명령어만 인식되고 하는 UI상에서 전혀 액션을 취하지 못하는 상황이라면 윈도우OS의 중요한 서비스를 죽여서 정상 리부팅을 진행해보는것도 괜찮지 않을까 생각합니다.

2017/01/15 20:13 2017/01/15 20:13