I'm going to take one for the team on this...
So you have hybrid Exchange and Office 365 and for some reason you wind up with an account with a local Exchange Mailbox and an Office 365 mailbox. After years of just delete the whole Office 365 account to fix the issue Microsoft finally gave us this:
Permanently Clear Previous Mailbox Info: https://blogs.technet.microsoft.com/exchange/2018/01/17/permanently-clear-previous-mailbox-info/
Great! That's awesome! I have a user right now that I need to fix. Wonderful. Glad I remember seeing that somewhere along the way.
{The actual command most people would use would be Set-User, but I use
the O365 prefix to my Office 365 powershell commands so as to not
clobber my local AD and Exchange powershell commands. -ED}
PS C:\Scripts\Exchange 2013> Set-O365User user@contoso.com -PermanentlyClearPreviousMailboxInfo
WARNING: The command completed successfully but no settings of 'user' have been modified.
What? Why not?
Why is Google only telling me of other people who are seeing this same error but now resolution?
Open support ticket. DELAY DELAY DELAY
Oh wait that user has an Exchange online license. Let's unselect that.
PS C:\Scripts\Exchange 2013> Set-O365User user@contoso.com -PermanentlyClearPreviousMailboxInfo
PS C:\Scripts\Exchange 2013>
Uhhhhhhhhhh... Genius! Well DUH! So there you are. I'm admitting that I made a pretty stupid mistake so you can read this and then not have to admit to anyone else that you did.
Friday, August 24, 2018
Friday, January 20, 2017
Hybrid Exchange mrsproxy.svc connection closed
I'm getting this error: The connection to the server 'ews.contoso.com' could not be completed. ---> Microsoft.Exchange.MailboxReplicationService.RemoteTransientException: The call to 'https://ews.contoso.com/EWS/mrsproxy.svc' failed. Error details: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. --> The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.. ---> Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. ---> Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
Nothing on Google helps at all! I put in a call to Office 365 support and the tech was actually worse than not helpful about this issue. At the start he mentioned that I would likely need to pay for a support ticket to get Exchange support. He then gave me 'best effort' support which included telling me to change all of my EWS virtual directory authentication to basic from Integrated Windows authentication, which of course Exchange warns will break Outlook Anywhere. That didn't fix it. His suggestion was to export to PST, delete the whole AD account for the user, create a new AD account with all the same user information, create a new local mailbox, and finally import the PST.
I have Exchange 2013 and Exchange 2016 in my org. They are behind a hardware load balancer. I have recreated the Migration Endpoint in Office 365 to no avail. Migrations were fine earlier this week. They are now broken. I have put the HLB into maintenance mode for two servers and I am only using one server to connect with for EWS hoping that would eliminate any persistence issues. I changed the timeout value from the working fine before 60 seconds to now still not working 600 seconds.
I now have an open paid Exchange support ticket with Microsoft. I will update this with findings/results.
On Prem Exchange support said it was an Office 365 issue. After a week migrations just started working again. No changes were made by me.
Nothing on Google helps at all! I put in a call to Office 365 support and the tech was actually worse than not helpful about this issue. At the start he mentioned that I would likely need to pay for a support ticket to get Exchange support. He then gave me 'best effort' support which included telling me to change all of my EWS virtual directory authentication to basic from Integrated Windows authentication, which of course Exchange warns will break Outlook Anywhere. That didn't fix it. His suggestion was to export to PST, delete the whole AD account for the user, create a new AD account with all the same user information, create a new local mailbox, and finally import the PST.
I have Exchange 2013 and Exchange 2016 in my org. They are behind a hardware load balancer. I have recreated the Migration Endpoint in Office 365 to no avail. Migrations were fine earlier this week. They are now broken. I have put the HLB into maintenance mode for two servers and I am only using one server to connect with for EWS hoping that would eliminate any persistence issues. I changed the timeout value from the working fine before 60 seconds to now still not working 600 seconds.
I now have an open paid Exchange support ticket with Microsoft. I will update this with findings/results.
On Prem Exchange support said it was an Office 365 issue. After a week migrations just started working again. No changes were made by me.
Tuesday, January 17, 2017
Exchange contact NDR IMCEAEX NT5 00000000000000000000000000000000
Another bare bones post here. I wish I actually understood WHY this happens. What I do know is this does happen and here is my fix.
If you get a contact from another org you might end up seeing NDR errors that look like the following:
IMCEAEX-_o=NT5_ou=00000000000000000000000000000000_cn=...
When you get the NDR back it looks like the correct address is filled in in the message headers. Only when you put your cursor over the person's name does the IMCEAEX address pop out. This is what it looks like:
I don't know why, but appearntly it has something to do with a bad LegacyExchangeDN?
To fix it I run this command daily against my OU that the contacts are in:
Get-MailContact -OrganizationalUnit "OU=MailContacts,OU=OffSite,DC=ad,DC=mydomain,DC=com" | Update-Recipient
You may need to rebuild the OAB after doing this to solve the problem *right now* but I don't know.
If you get a contact from another org you might end up seeing NDR errors that look like the following:
IMCEAEX-_o=NT5_ou=00000000000000000000000000000000_cn=...
When you get the NDR back it looks like the correct address is filled in in the message headers. Only when you put your cursor over the person's name does the IMCEAEX address pop out. This is what it looks like:
Delivery has failed to these recipients or groups:
LastName, FirstName
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues, please contact your helpdesk.
Diagnostic information for administrators:
Generating server: mail.contoso.com
IMCEAEX-_o=NT5_ou=00000000000000000000000000000000_cn={32 char number}@mail.contoso.com
Remote Server returned '550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found'
Original message headers: ...
I don't know why, but appearntly it has something to do with a bad LegacyExchangeDN?
To fix it I run this command daily against my OU that the contacts are in:
Get-MailContact -OrganizationalUnit "OU=MailContacts,OU=OffSite,DC=ad,DC=mydomain,DC=com" | Update-Recipient
You may need to rebuild the OAB after doing this to solve the problem *right now* but I don't know.
Thursday, April 21, 2016
mrsproxy.svc authentication scheme 'Negotiate' (403) Forbidden
The call to 'https://server.contoso.com/EWS/mrsproxy.svc' failed. Error details: The HTTP request was forbidden with client a
uthentication scheme 'Negotiate'. --> The remote server returned an error: (403) Forbidden..
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemoteTransientException
+ FullyQualifiedErrorId : [Server=BL2PR02MB2129,RequestId=cd8a2403-0b3c-4fee-ad2c-a27305435b36,TimeStamp=4/20/2016
8:51:30 PM] [FailureCategory=Cmdlet-RemoteTransientException] 8E22672D,Microsoft.Exchange.Management.Migration.Ma
ilboxReplication.MoveRequest.NewMoveRequest
+ PSComputerName : ps.outlook.com
Run:
Get-WebServicesVirtualDirectory |FL
Compare the URL listed above with the URLs in ExternalUrl and InternalUrl and adjust accordingly. Create a new migration endpoint in Office 365 that uses the new name.
It's been a very long day. I'll try to give a proper update once I have had some downtime.
[Edit below]
So in the planning for going from Exchange 2010 to Exchange 2013 I did a lot of research on load balancing and namespaces. I decided to go for the each service has its own namespace model so that if for some reason the address book was down that owa would still show as alive. Well I got a lesson in things you still don't know about Exchange so you're gonna learn today.
On 2010 everything was accessed via one namespace like mail.contoso.com. So in our hybrid environment with Office 365 the migration endpoint mapping pointed to mail.contoso.com. When I cut over the namespaces to 2013 I left mail.contoso.com for the friendly owa name and broke out all the other names. I started getting errors in my scripts that I made to migrate mailboxes to Office 365. The error listed above. Of course it wasn't much help to determine what the actual problem was.
After lots of digging and hair pulling I finally stumbled upon the suggestion to use Get-WebServicesVirtualDirectory |FL and look for something else that was useless. However I did note that the URL was not mail.contoso.com that was in there. Not trusting that observation I changed the authentication and got the same error. After that I removed and remade the migration endpoint mapping. It tried to autodiscover the setting and failed. I then put in ews.contoso.com and it was happy and my scripts were happy.
uthentication scheme 'Negotiate'. --> The remote server returned an error: (403) Forbidden..
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], RemoteTransientException
+ FullyQualifiedErrorId : [Server=BL2PR02MB2129,RequestId=cd8a2403-0b3c-4fee-ad2c-a27305435b36,TimeStamp=4/20/2016
8:51:30 PM] [FailureCategory=Cmdlet-RemoteTransientException] 8E22672D,Microsoft.Exchange.Management.Migration.Ma
ilboxReplication.MoveRequest.NewMoveRequest
+ PSComputerName : ps.outlook.com
Run:
Get-WebServicesVirtualDirectory |FL
Compare the URL listed above with the URLs in ExternalUrl and InternalUrl and adjust accordingly. Create a new migration endpoint in Office 365 that uses the new name.
It's been a very long day. I'll try to give a proper update once I have had some downtime.
[Edit below]
So in the planning for going from Exchange 2010 to Exchange 2013 I did a lot of research on load balancing and namespaces. I decided to go for the each service has its own namespace model so that if for some reason the address book was down that owa would still show as alive. Well I got a lesson in things you still don't know about Exchange so you're gonna learn today.
On 2010 everything was accessed via one namespace like mail.contoso.com. So in our hybrid environment with Office 365 the migration endpoint mapping pointed to mail.contoso.com. When I cut over the namespaces to 2013 I left mail.contoso.com for the friendly owa name and broke out all the other names. I started getting errors in my scripts that I made to migrate mailboxes to Office 365. The error listed above. Of course it wasn't much help to determine what the actual problem was.
After lots of digging and hair pulling I finally stumbled upon the suggestion to use Get-WebServicesVirtualDirectory |FL and look for something else that was useless. However I did note that the URL was not mail.contoso.com that was in there. Not trusting that observation I changed the authentication and got the same error. After that I removed and remade the migration endpoint mapping. It tried to autodiscover the setting and failed. I then put in ews.contoso.com and it was happy and my scripts were happy.
Wednesday, December 9, 2015
Edge transport doesn't talk to 2013 but works just fine with 2010
I could not get my Exchange 2010 Edge Transport to talk to my new Exchange 2013 server. The Edge Transport continued to function just fine with Exchange 2010. All the mail from my new 2013 box that was supposed to be going through the Edge Transport was just sitting in the mail queue. I could see MSExchange EdgeSync 1032 errors in the logs. I was also getting MSexchangeTransport 12023 errors in the event logs. These two issues are related but I didn't know it last week when I found out that I was queuing mail. I had to make a workaround to get mail flowing. It wasn't until today that I fixed one and that lead me to a useful error of MSExchange EdgeSync 1033 that gave a certificate error.
I had to run
Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services SMTP
to clear MSexchangeTransport 12023 error. Using the ECP to set the "already set" SMTP flag did not work and no error or information was shown. Running that command from EMS asked if I wanted to replace the default SMTP certificate. I answered yes and it told me there was an Edge Transport problem and to resubscribe. Below is a partial screenshot.
I did the resubscription and all is good now. Now I just have to tear down my workaround.
I had to run
Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services SMTP
to clear MSexchangeTransport 12023 error. Using the ECP to set the "already set" SMTP flag did not work and no error or information was shown. Running that command from EMS asked if I wanted to replace the default SMTP certificate. I answered yes and it told me there was an Edge Transport problem and to resubscribe. Below is a partial screenshot.
I did the resubscription and all is good now. Now I just have to tear down my workaround.
Tuesday, December 1, 2015
Site to Zone Assignment list and IEHarden
I am going to apologize for knowingly posting something incomplete on here. Was at work late working on this issue and I'm in zombie mode today.
If your Site to Zone Assignment list via GPO seems not to be working, and especially if it is working for some users and not other users it could be a registry setting. If a user profile is made before changing the IE Enhanced Security Mode it will inherit the registry setting. Then you change the setting for users via Server Manger -> "Configure IE ESC" new profiles are created without the registry setting.
I connected via remote registry and under the user section for my user sid I went to
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
and found the value IEHarden set to 1. If I set it to 0 and restarted IE it would do what I needed it to and expected it to.
I used this to solve my problems with the error of "an add-on for this website failed to run" and wouldn't start Java for a particular set of allowed sites.
If your Site to Zone Assignment list via GPO seems not to be working, and especially if it is working for some users and not other users it could be a registry setting. If a user profile is made before changing the IE Enhanced Security Mode it will inherit the registry setting. Then you change the setting for users via Server Manger -> "Configure IE ESC" new profiles are created without the registry setting.
I connected via remote registry and under the user section for my user sid I went to
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
and found the value IEHarden set to 1. If I set it to 0 and restarted IE it would do what I needed it to and expected it to.
I used this to solve my problems with the error of "an add-on for this website failed to run" and wouldn't start Java for a particular set of allowed sites.
Tuesday, October 20, 2015
Upgrading Dirsync to Azure Active Directory Connect (AADC) a cautionary tale
I usually try to be pretty thorough about things when I post. I wasn't planning on posting a here's how you upgrade post so I have no screen shots or errors. Basically the upgrade is next next next. The one problem that I had was that I needed to change the schedule for the sync process. This is now a scheduled task that is automagically setup in AADC.
When you change the schedule DO NOT JUST CHANGE THE PASSWORD ON THE CREATED SERVICE ACCOUNT. Make a new service account, or use another account to edit the scheduled task and run it. If you want to change the password on the created service account it will mess up the encryption keys in AADC and you will have to jump through some hoops. It is not a huge deal, but it takes way way less time to just make or use another account to run the task. Just save yourself some time.
When you change the schedule DO NOT JUST CHANGE THE PASSWORD ON THE CREATED SERVICE ACCOUNT. Make a new service account, or use another account to edit the scheduled task and run it. If you want to change the password on the created service account it will mess up the encryption keys in AADC and you will have to jump through some hoops. It is not a huge deal, but it takes way way less time to just make or use another account to run the task. Just save yourself some time.
Tuesday, October 13, 2015
Forced reboots from WSUS
So lets say that you are oh I don't know upgrading Dirsync to the new hotness. You do your research and everyone says it's just next next next and then happiness. You don't even have to install any prereqs it will do that all for you. (I'm looking at you https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-dirsync-upgrade-get-started/) Well you have to update powershell and .NET. You do that and reboot a couple times and then start the new Azure Active Directory Connect install. It just all works.
Until you're in the middle of a full sync process and WSUS says hey you have new software that needs patches! Reboot now! I don't care what database operations you are doing that I am going to mess up! BOW TO MY EVERY WHIM!
So I Google blocking reboots due to an update and every single suggestion I find says change this and reboot and you're golden. What part of blocking a reboot do you not understand here people?
So I rush to download Process Explorer onto my machine. I do the process find over the WSUS I'M GOING TO DESTROY YOU popup (I think it might actually say something like your machine is going to reboot in X time would you like to reboot now). I right click that and go to the Threads tab and Suspend each thread. That appears to have saved my hour of database operations from being interrupted. I'll go in and unsuspend all that after my full sync is done and then let the server reboot for updates ON MY SCHEDULE.
Until you're in the middle of a full sync process and WSUS says hey you have new software that needs patches! Reboot now! I don't care what database operations you are doing that I am going to mess up! BOW TO MY EVERY WHIM!
So I Google blocking reboots due to an update and every single suggestion I find says change this and reboot and you're golden. What part of blocking a reboot do you not understand here people?
So I rush to download Process Explorer onto my machine. I do the process find over the WSUS I'M GOING TO DESTROY YOU popup (I think it might actually say something like your machine is going to reboot in X time would you like to reboot now). I right click that and go to the Threads tab and Suspend each thread. That appears to have saved my hour of database operations from being interrupted. I'll go in and unsuspend all that after my full sync is done and then let the server reboot for updates ON MY SCHEDULE.
Thursday, October 8, 2015
Installing Exchange 2013 (Something Went Wrong)
I'm not going to go into grand detail today. Just a few quick notes on installing Exchange 2013 for the first time. I have 2010 already in my org.
1) You can just install from the latest CU rollup. I installed directly from 2013 CU9.
2) Install your first server as enterprise admin even if you have previously done the AD prep steps. The first install of a 2013 server likes to create a user in root domain of your forest. My Exchange servers live in a child domain and I got access denied when doing some user actions for the SystemMailbox.
3) When you go to access the ECP page you pretty much have to add ?ExchClientVer=15 at the end of the URL to get to see the ECP (https://mail.contoso.com/ecp/?ExchClientVer=15). If not it just redirects you to a something went wrong page. This appears to be because of the bug in the installer below.
4) Apparently there is a bug in some of the later CU installation processes. After finalizing the install of 2013 and setting up the virtual directories I migrated a mailbox. That mailbox was completely inaccessible. Outlook couldn't open it saying a folder was unavailable and OWA just gave the something went wrong error. I was not able to even access https://server.contoso.com/autodiscover/autodiscover.xml. It gave an error about
Parser Error Message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
The application logs were filled with ASP.NET 4.0.30319.0 Event code: 3008.
From what I found on a couple other blogs is that MS split a file into two and the installer doesn't properly create the second file in all directories as it should in later CU updates.
Copy the sharedwebconfig.config file from:
E:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy
To:
E:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
I'll now post the full error messages for completeness.
From IE:
Server Error in '/Autodiscover' Application.
Parser Error Message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Source Error:
Source File: E:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Autodiscover\web.config Line: 41
Assembly Load Trace: The following information can be helpful to determine why the assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' could not be loaded.
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34248
From Application Event Log:
Event code: 3008
Event message: A configuration error has occurred.
Event time: 10/7/2015 4:12:01 PM
Event time (UTC): 10/7/2015 10:12:01 PM
Event ID: b89e6ff51088402180f450f7ad847cd1
Event sequence: 1
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2/ROOT/Rpc-7-130887295216281384
Trust level: Full
Application Virtual Path: /Rpc
Application Path: C:\Windows\System32\RpcProxy\
Machine name: HOSTNAME
Process information:
Process ID: 10544
Process name: w3wp.exe
Account name: NT AUTHORITY\SYSTEM
Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (C:\Windows\System32\RpcProxy\web.config line 37)
at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
at System.Web.Configuration.AssemblyInfo.get_AssemblyInternal()
at System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig)
at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded)
at System.Web.Compilation.BuildManager.ExecutePreAppStart()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)
Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
Request information:
Request URL: https://FQDN:444/rpc/rpcproxy.dll?FQDN:6001
Request path: /rpc/rpcproxy.dll
User host address:
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\SYSTEM
Thread information:
Thread ID: 28
Thread account name: NT AUTHORITY\SYSTEM
Is impersonating: False
Stack trace: at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
at System.Web.Configuration.AssemblyInfo.get_AssemblyInternal()
at System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig)
at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded)
at System.Web.Compilation.BuildManager.ExecutePreAppStart()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)
Custom event details:
1) You can just install from the latest CU rollup. I installed directly from 2013 CU9.
2) Install your first server as enterprise admin even if you have previously done the AD prep steps. The first install of a 2013 server likes to create a user in root domain of your forest. My Exchange servers live in a child domain and I got access denied when doing some user actions for the SystemMailbox.
3) When you go to access the ECP page you pretty much have to add ?ExchClientVer=15 at the end of the URL to get to see the ECP (https://mail.contoso.com/ecp/?ExchClientVer=15). If not it just redirects you to a something went wrong page. This appears to be because of the bug in the installer below.
4) Apparently there is a bug in some of the later CU installation processes. After finalizing the install of 2013 and setting up the virtual directories I migrated a mailbox. That mailbox was completely inaccessible. Outlook couldn't open it saying a folder was unavailable and OWA just gave the something went wrong error. I was not able to even access https://server.contoso.com/autodiscover/autodiscover.xml. It gave an error about
Parser Error Message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Line 41: <add assembly="Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" />
The application logs were filled with ASP.NET 4.0.30319.0 Event code: 3008.
From what I found on a couple other blogs is that MS split a file into two and the installer doesn't properly create the second file in all directories as it should in later CU updates.
Copy the sharedwebconfig.config file from:
E:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy
To:
E:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
I'll now post the full error messages for completeness.
From IE:
Server Error in '/Autodiscover' Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.Parser Error Message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Source Error:
|
Source File: E:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Autodiscover\web.config Line: 41
Assembly Load Trace: The following information can be helpful to determine why the assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' could not be loaded.
|
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34248
From Application Event Log:
Event code: 3008
Event message: A configuration error has occurred.
Event time: 10/7/2015 4:12:01 PM
Event time (UTC): 10/7/2015 10:12:01 PM
Event ID: b89e6ff51088402180f450f7ad847cd1
Event sequence: 1
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2/ROOT/Rpc-7-130887295216281384
Trust level: Full
Application Virtual Path: /Rpc
Application Path: C:\Windows\System32\RpcProxy\
Machine name: HOSTNAME
Process information:
Process ID: 10544
Process name: w3wp.exe
Account name: NT AUTHORITY\SYSTEM
Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (C:\Windows\System32\RpcProxy\web.config line 37)
at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
at System.Web.Configuration.AssemblyInfo.get_AssemblyInternal()
at System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig)
at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded)
at System.Web.Compilation.BuildManager.ExecutePreAppStart()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)
Could not load file or assembly 'Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
Request information:
Request URL: https://FQDN:444/rpc/rpcproxy.dll?FQDN:6001
Request path: /rpc/rpcproxy.dll
User host address:
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\SYSTEM
Thread information:
Thread ID: 28
Thread account name: NT AUTHORITY\SYSTEM
Is impersonating: False
Stack trace: at System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
at System.Web.Configuration.AssemblyInfo.get_AssemblyInternal()
at System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig)
at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded)
at System.Web.Compilation.BuildManager.ExecutePreAppStart()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)
Custom event details:
Wednesday, July 15, 2015
Exchange 2010 SP3 /mRecoverServer (the short version)
We "have" a HA Exchange 2010 setup. The 2 x CAS/HT servers are Hyper-V and WLB. The 2 x MBX/HT servers are clustered physical boxes. At one point Outlook client connections just started dropping from Exchange seemingly at random. After trying tons of things I found that after I rebooted one of the hosts it would calm down for a while. Eventually I turned off the box and everything has been great since. I have no clue why it was doing that. I believe that something got borked inside Exchange on that box.
After having that box off for a while it was decided that I start testing Exchange 2013 on it. I went to uninstall Exchange (once I was out of a critical work period) and it gave me all kinds of errors and would not uninstall gracefully. I ran a setup uninstall command and that got me further but eventually failed. That box was certainly in a failed state.
I knew that I couldn't just format c: and put 2013 on it and go on with my life as a higher up suggested to me. I had to gracefully uninstall Exchange off that box. (Well I didn't have to, but I *DID NOT* want to launch ADSIedit at all!) I started doing research and found the recoverserver switch. I really didn't want to format c: either and spend a day installing Windows and getting patches and doing all that fun stuff. I figured that I could just say maybe delete a Microsoft directory under Program Files and recover from there. Here is my trials and tribulations of a failed Exchange 2010 SP3 uninstall and the attempts to use recoverserver to get it back installed again:
GUI install certainly didn't work. We all knew that would be the case. So after a bit of searching I found the recoverserver command (which failed):
I also need to point out that I had problems running the install because I had all the services set to Disabled. The installer needs to be able to start services or it will fail out.
Error text:
The parameters specified are either missing additional required parameters or are not valid together.
To list the available command-line parameters, type Setup /?
I couldn't spot the subtle error. Finally figured out the switch TargetDir needs a : between it and the target.
Working command:
Setup /m:RecoverServer /donotstartTransport /TargetDir:"E:\Program Files\Microsoft\Exchange Server\V14"
The previous installation path could not be found in the registry. Only disaster recovery mode is available.
The previously installed version could not be determined from the registry. Only disaster recovery mode is available.
Exchange Server setup encountered an error.
Fix:
looked at registry path HKLM\software\Microsoft\Exchange server\V14
- deleted Key "Midfilecopy" and "Setup" under V14
DID NOT REBOOT THE SERVER
Source: https://social.technet.microsoft.com/Forums/exchange/en-US/209604ce-2f74-41b1-b0eb-c5ad19ece305/failed-to-upgrad-exchange-2010-sp1-the-previous-installation-path-could-not-be-found-in-the?forum=exchange2010
Error text:
Setup previously failed while performing the action "BuildToBuildUpgrade". You can't resume setup by performing the action "DisasterRecovery".
Exchange Server setup encountered an error.
Fix:
Under the registry Key that corresponds to the "installed" roles:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\<"installed" roles>
Delete Value "Action" with Data of "Install"
(If you want to skip past Error #4 then do the following while you're here:
Delete Value "Watermark" with Data of "Powershellsomethingsomethingsomething")
Source: http://baudlabs.com/setup-previously-failed-while-performing-the-action-install-error-during-exchange-2010-sp2-upgrade/
A Setup failure previously occurred while installing the HubTransport role. Either run Setup again for just this role, or remove the role using Control Panel.
Fix:
You know that place you were just in?
Under the registry Key that corresponds to the "installed" roles:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\<"installed" roles>
Delete Value "Watermark" with Data of "Powershellsomethingsomethingsomething"
Source: https://myrefspot.wordpress.com/2013/01/10/exchange-2010-server-recovery-failed-on-hub-transport-role/
Installing product C:\Temp\Exchange SP3 Install\exchangeserver.msi failed.
Fatal error during installation. Error code is 1603.
Fix:
I copied the install files over from a central location. In the Updates folder under the extracted SP3 setup files at one point someone (probably me) placed the CU2 update in that directory. It took me forever to figure this one out. I deleted the file and the 1603 error went away. It's always a good idea to just redownload and reextract the SP3 file to the machine you are working on in case some idiot messes up your source files directory.
[ERROR] The virtual directory 'PowerShell-Proxy' already exists under 'FQDN.Server.Name/Default Web Site'.
Fix:
Went into IIS and deleted the PowerShell-Proxy virtual directory.
Had to remove the setup Keys and Values from under the registry as above.
Had to reboot after this step since it got far enough into the install.
The following error was generated when "$error.Clear();
$wevtutil= join-path (join-path $env:SystemRoot system32) wevtutil.exe;
$manifestPath = [System.IO.Path]::Combine($RoleInstallPath, "Scripts\TSCrimsonManifest.man");
Start-SetupProcess -Name:"$wevtutil" -Args:"im `"$manifestPath`" "
" was run: "Process execution failed with exit code 87.".
Fix:
Delete the registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Microsoft-Exchange-Troubleshooters/Operational
Had to remove the PowerShell-Proxy virtual directory.
Had to remove the setup Keys and Values from under the registry as above.
Had to reboot after this step since it got far enough into the install.
Source: https://social.technet.microsoft.com/Forums/exchange/en-US/17619f0e-bd05-4e40-9f60-49fc1bbb1602/problems-installing-mailbox-role-on-exchange-server-2010-sp3?forum=exchange2010
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\
Delete Keys: "Midfilecopy" and "Setup"
Under the 'server roles' Keys delete any Values that are "Action" and "Watermark"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\
Delete Key: Microsoft-Exchange-Troubleshooters/Operational
In IIS:
Delete the PowerShell-Proxy virtual directory
Make sure your install files are good and do not have any extra stuff included in the folders.
Run an administrative command prompt then start setup from within the extracted SP3 folder making note of the subtleties of the command syntax:
Setup /m:RecoverServer /donotstartTransport /TargetDir:"E:\Program Files\Microsoft\Exchange Server\V14"
After having that box off for a while it was decided that I start testing Exchange 2013 on it. I went to uninstall Exchange (once I was out of a critical work period) and it gave me all kinds of errors and would not uninstall gracefully. I ran a setup uninstall command and that got me further but eventually failed. That box was certainly in a failed state.
I knew that I couldn't just format c: and put 2013 on it and go on with my life as a higher up suggested to me. I had to gracefully uninstall Exchange off that box. (Well I didn't have to, but I *DID NOT* want to launch ADSIedit at all!) I started doing research and found the recoverserver switch. I really didn't want to format c: either and spend a day installing Windows and getting patches and doing all that fun stuff. I figured that I could just say maybe delete a Microsoft directory under Program Files and recover from there. Here is my trials and tribulations of a failed Exchange 2010 SP3 uninstall and the attempts to use recoverserver to get it back installed again:
GUI install certainly didn't work. We all knew that would be the case. So after a bit of searching I found the recoverserver command (which failed):
I also need to point out that I had problems running the install because I had all the services set to Disabled. The installer needs to be able to start services or it will fail out.
Error #1:
Setup /M:RecoverServer /TargetDir "E:\Program Files\Microsoft\Exchange Server\V14" /donotstartTransportError text:
The parameters specified are either missing additional required parameters or are not valid together.
To list the available command-line parameters, type Setup /?
I couldn't spot the subtle error. Finally figured out the switch TargetDir needs a : between it and the target.
Working command:
Setup /m:RecoverServer /donotstartTransport /TargetDir:"E:\Program Files\Microsoft\Exchange Server\V14"
Error #2:
Error text:The previous installation path could not be found in the registry. Only disaster recovery mode is available.
The previously installed version could not be determined from the registry. Only disaster recovery mode is available.
Exchange Server setup encountered an error.
Fix:
looked at registry path HKLM\software\Microsoft\Exchange server\V14
- deleted Key "Midfilecopy" and "Setup" under V14
DID NOT REBOOT THE SERVER
Source: https://social.technet.microsoft.com/Forums/exchange/en-US/209604ce-2f74-41b1-b0eb-c5ad19ece305/failed-to-upgrad-exchange-2010-sp1-the-previous-installation-path-could-not-be-found-in-the?forum=exchange2010
Error #3:
Error text:
Setup previously failed while performing the action "BuildToBuildUpgrade". You can't resume setup by performing the action "DisasterRecovery".
Exchange Server setup encountered an error.
Fix:
Under the registry Key that corresponds to the "installed" roles:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\<"installed" roles>
Delete Value "Action" with Data of "Install"
(If you want to skip past Error #4 then do the following while you're here:
Delete Value "Watermark" with Data of "Powershellsomethingsomethingsomething")
Source: http://baudlabs.com/setup-previously-failed-while-performing-the-action-install-error-during-exchange-2010-sp2-upgrade/
Error #4:
Error text:A Setup failure previously occurred while installing the HubTransport role. Either run Setup again for just this role, or remove the role using Control Panel.
Fix:
You know that place you were just in?
Under the registry Key that corresponds to the "installed" roles:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\<"installed" roles>
Delete Value "Watermark" with Data of "Powershellsomethingsomethingsomething"
Source: https://myrefspot.wordpress.com/2013/01/10/exchange-2010-server-recovery-failed-on-hub-transport-role/
Error #5:
Error text:Installing product C:\Temp\Exchange SP3 Install\exchangeserver.msi failed.
Fatal error during installation. Error code is 1603.
Fix:
I copied the install files over from a central location. In the Updates folder under the extracted SP3 setup files at one point someone (probably me) placed the CU2 update in that directory. It took me forever to figure this one out. I deleted the file and the 1603 error went away. It's always a good idea to just redownload and reextract the SP3 file to the machine you are working on in case some idiot messes up your source files directory.
Error #6:
Error text:[ERROR] The virtual directory 'PowerShell-Proxy' already exists under 'FQDN.Server.Name/Default Web Site'.
Fix:
Went into IIS and deleted the PowerShell-Proxy virtual directory.
Had to remove the setup Keys and Values from under the registry as above.
Had to reboot after this step since it got far enough into the install.
Error #7:
Error text:The following error was generated when "$error.Clear();
$wevtutil= join-path (join-path $env:SystemRoot system32) wevtutil.exe;
$manifestPath = [System.IO.Path]::Combine($RoleInstallPath, "Scripts\TSCrimsonManifest.man");
Start-SetupProcess -Name:"$wevtutil" -Args:"im `"$manifestPath`" "
" was run: "Process execution failed with exit code 87.".
Fix:
Delete the registry Key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Microsoft-Exchange-Troubleshooters/Operational
Had to remove the PowerShell-Proxy virtual directory.
Had to remove the setup Keys and Values from under the registry as above.
Had to reboot after this step since it got far enough into the install.
Source: https://social.technet.microsoft.com/Forums/exchange/en-US/17619f0e-bd05-4e40-9f60-49fc1bbb1602/problems-installing-mailbox-role-on-exchange-server-2010-sp3?forum=exchange2010
Summary:
In the registry:\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\
Delete Keys: "Midfilecopy" and "Setup"
Under the 'server roles' Keys delete any Values that are "Action" and "Watermark"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\
Delete Key: Microsoft-Exchange-Troubleshooters/Operational
In IIS:
Delete the PowerShell-Proxy virtual directory
Make sure your install files are good and do not have any extra stuff included in the folders.
Run an administrative command prompt then start setup from within the extracted SP3 folder making note of the subtleties of the command syntax:
Setup /m:RecoverServer /donotstartTransport /TargetDir:"E:\Program Files\Microsoft\Exchange Server\V14"
Friday, April 24, 2015
Exchange 2010 calendar emailing people for no reason
Problem: Exchange 2010 is sending out calendar invite declined and accepted replies to seemingly random people. In my situation we have an HR.Office@contoso.com email address. Of course HR staff come and go about like the leaves on trees. They come and go and the HR.Office@contoso.com email address stays the same. Well mostly the same. Delegates to the calendar get added (and not by me, that is purely a user function as far as I am concerned). Users being users they don't ever go in and clean anything up when someone moves on. I am certain they think the Exchange Admin should be earning that fat check by reading minds and cleaning all that up.
First things first.
I started down this path thanks to two blog posts:
First I found this one that got me on the right path:
Then I found this one the next day that really helped me out:
Using MFCMAPI to delete delegate rules from mailbox
Of course I also need to point you to the tool to do all this with:
MFCMAPI
The ticket I got stated that Beth and Mary were getting responses to calendar invites to the HR.Office@contoso.com. They said that this has been happening for a long time and they are finally getting tired of getting them. It appears that this could have been going on for years. According to what I have heard both of those women worked in HR before I even showed up to the organization. Uma, who is the new HR director, copied and pasted the text of the calendar reply into the ticket.
The first thing that I think is that there is a rule setup to forward those replies to Beth and Mary. Turns out I'm right, but it's a long road to get there. To prove that I'm right I go to the Message Tracking Log Explorer.
As you can see Uma Declines the calendar invite and the response goes to HR.Office@contoso.com. Also according to a mailbox rule Uma@contoso.com sends the response to Beth@contoso.com and Mary@contoso.com.
At this point I get myself full access to both Uma@contoso.com and HR.Office@contoso.com. I try to look at the mailbox rules from my Outlook client. I was only able to see my own. So I search for a way to look at mailbox rules via Powershell. I find the command:
Get-InboxRule
I try:
Get-InboxRule Uma@contoso.com
and
Get-InboxRule HR.Office@contoso.com
for both I get the following error:
The specified mailbox "contoso.com/Accounts/domainadmin" doesn't exist. Reason: contoso.com/Accounts/domainadmin isn't a mailbox user.
+ CategoryInfo : NotSpecified: (0:Int32) [Get-InboxRule], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : AD6EC4C4,Microsoft.Exchange.Management.RecipientTasks.GetInboxRule
+ PSComputerName : exchange.contoso.com
After digging a bit I figure out that I have to use:
Get-Mailbox Uma@contoso.com | Get-InboxRule
This command will actually show me all the rules that are enabled on the mailbox. Well kinda, as I found out later it doesn't. Also something of note. You will get the following error (or, um, helpful output from Powershell) if the user doesn't have any mailbox rules setup:
The operation couldn't be performed because 'contoso.com/DifferentAccounts/Lastname, Uma\' couldn'
t be found.
+ CategoryInfo : NotSpecified: (:) [Get-InboxRule], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : 112BED4B,Microsoft.Exchange.Management.RecipientTasks.GetInboxRule
+ PSComputerName : exchange.contoso.com
Running Get-Mailbox HR.Office@contoso.com | Get-InboxRule returns me normal Powershell output:
Name Enabled Priority RuleIdentity
---- ------- -------- ------------
Clear categories on mail (... True 1 16791953785139232769
Clearly nothing helpful. A bit disgruntled I do a lot of Google searching for calendar invite sending emails and mailboxrule. It is at this point I find that there are hidden mailbox rules in Exchange. Oh joy! Oh wonderful! Even better is that there isn't any good way to figure out what is going on because the are not only hidden from the user, they are hidden from the Exchange admin too. You can't surface them in Powershell.
At this point I start a discovery search on my four mailboxes so that I can actually get to the mail items and look at them. Going through the mailbox for Uma and HR.Office shows no sent item that goes to Beth or Mary. Aside from going to their offices and looking through their deleted item recovery I am not going to be able to see an actual mail item. I start the discovery search and when it completes I drill down to the deleted item and double click on it. Once in the item I go to file -> properties to look at the headers:
Received: from exchange.contoso.com by exchange.contoso.com with Microsoft
SMTP Server id 14.03.0224.002; Wed, 22 Apr 2015 08:18:51 -0600
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: "Lastname, Uma" <Uma@contoso.com>
To: "Person, Gone"
<IMCEAEX-_o=contoso_cn=DisabledAccounts_cn=GONE@contoso.local>, "Bright, Mary" <Mary@contoso.com>, "Short, Beth" <Beth@contoso.com>
Subject: Declined: Testing 2
Thread-Topic: Testing 2
Thread-Index: RandomLooking+SetofCharacters=
Date: Wed, 22 Apr 2015 14:18:50 +0000
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: exchange.contoso.com
X-MS-Has-Attach:
X-Auto-Response-Suppress: All
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Inbox-Rules-Loop: HR.Office@contoso.com
X-MS-TNEF-Correlator: GUIDLookingThing
x-originating-ip: [192.168.15.254]
MIME-Version: 1.0
Message-Id: <longrandomhexnumber@exchange.contoso.com>
This header provided me the key, but I didn't know it yet:
X-MS-Exchange-Inbox-Rules-Loop: HR.Office@contoso.com
That is the mailbox that has the hidden mailbox rule on it that needed to be deleted to stop the mail from going to the "random" people. (Quick note: I called Microsoft support and talked to someone in a foreign country. He had a very difficult time figuring out what the issue even was. I spent 45 minutes on the phone trying to explain to him what was happening and when it was quitting time for me he still didn't sound like he could understand what was happening when we were going to pick up working on this the next day. The rant here is that Microsoft support does not appear to employ people familiar with the nuts and bolts of the products they are supposed to support. I really don't care where in the world they are. I care that they seem lost when I am trying to explain what the problem is.)
When I get out of the shower the next morning I am convinced that the heart of the problem are those pesky hidden mailbox rules. I go back to work and start digging using MFCMAPI. What I find is that I need to delete that hidden rule on the HR.Office mailbox. Run it on your local desktop.
Open MFCMAPI:
Logon:
Select Outlook Profile:
Double click the HR.Office mailbox:
A new window will open. Expand Root Container -> Top of Information Store -> Inbox:
(If Top of Information Store is not there and you have IPM Subtree then your local Outlook in in cached mode. You need to change this. If you don't know what I'm talking about then you should stop what you're doing and not do anything else.)
Right click Inbox -> Other tables -> Rules table:
Find the hidden mailbox rule:
Delete the hidden mailbox rule:
That pretty much solved the problem that I had. Of course I don't know yet if there are other problems that this caused. I don't believe so. If you're Exchange Admin I am sure you are fully aware to be afraid of doing some of this stuff. Of course I also remember that at the last job this same problem cropped up and no one knew how to solve it.
First things first.
I started down this path thanks to two blog posts:
First I found this one that got me on the right path:
Then I found this one the next day that really helped me out:
Using MFCMAPI to delete delegate rules from mailbox
Of course I also need to point you to the tool to do all this with:
MFCMAPI
The ticket I got stated that Beth and Mary were getting responses to calendar invites to the HR.Office@contoso.com. They said that this has been happening for a long time and they are finally getting tired of getting them. It appears that this could have been going on for years. According to what I have heard both of those women worked in HR before I even showed up to the organization. Uma, who is the new HR director, copied and pasted the text of the calendar reply into the ticket.
The first thing that I think is that there is a rule setup to forward those replies to Beth and Mary. Turns out I'm right, but it's a long road to get there. To prove that I'm right I go to the Message Tracking Log Explorer.
As you can see Uma Declines the calendar invite and the response goes to HR.Office@contoso.com. Also according to a mailbox rule Uma@contoso.com sends the response to Beth@contoso.com and Mary@contoso.com.
At this point I get myself full access to both Uma@contoso.com and HR.Office@contoso.com. I try to look at the mailbox rules from my Outlook client. I was only able to see my own. So I search for a way to look at mailbox rules via Powershell. I find the command:
Get-InboxRule
I try:
Get-InboxRule Uma@contoso.com
and
Get-InboxRule HR.Office@contoso.com
for both I get the following error:
The specified mailbox "contoso.com/Accounts/domainadmin" doesn't exist. Reason: contoso.com/Accounts/domainadmin isn't a mailbox user.
+ CategoryInfo : NotSpecified: (0:Int32) [Get-InboxRule], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : AD6EC4C4,Microsoft.Exchange.Management.RecipientTasks.GetInboxRule
+ PSComputerName : exchange.contoso.com
After digging a bit I figure out that I have to use:
Get-Mailbox Uma@contoso.com | Get-InboxRule
This command will actually show me all the rules that are enabled on the mailbox. Well kinda, as I found out later it doesn't. Also something of note. You will get the following error (or, um, helpful output from Powershell) if the user doesn't have any mailbox rules setup:
The operation couldn't be performed because 'contoso.com/DifferentAccounts/Lastname, Uma\' couldn'
t be found.
+ CategoryInfo : NotSpecified: (:) [Get-InboxRule], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : 112BED4B,Microsoft.Exchange.Management.RecipientTasks.GetInboxRule
+ PSComputerName : exchange.contoso.com
Running Get-Mailbox HR.Office@contoso.com | Get-InboxRule returns me normal Powershell output:
Name Enabled Priority RuleIdentity
---- ------- -------- ------------
Clear categories on mail (... True 1 16791953785139232769
Clearly nothing helpful. A bit disgruntled I do a lot of Google searching for calendar invite sending emails and mailboxrule. It is at this point I find that there are hidden mailbox rules in Exchange. Oh joy! Oh wonderful! Even better is that there isn't any good way to figure out what is going on because the are not only hidden from the user, they are hidden from the Exchange admin too. You can't surface them in Powershell.
At this point I start a discovery search on my four mailboxes so that I can actually get to the mail items and look at them. Going through the mailbox for Uma and HR.Office shows no sent item that goes to Beth or Mary. Aside from going to their offices and looking through their deleted item recovery I am not going to be able to see an actual mail item. I start the discovery search and when it completes I drill down to the deleted item and double click on it. Once in the item I go to file -> properties to look at the headers:
Received: from exchange.contoso.com by exchange.contoso.com with Microsoft
SMTP Server id 14.03.0224.002; Wed, 22 Apr 2015 08:18:51 -0600
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: "Lastname, Uma" <Uma@contoso.com>
To: "Person, Gone"
<IMCEAEX-_o=contoso_cn=DisabledAccounts_cn=GONE@contoso.local>, "Bright, Mary" <Mary@contoso.com>, "Short, Beth" <Beth@contoso.com>
Subject: Declined: Testing 2
Thread-Topic: Testing 2
Thread-Index: RandomLooking+SetofCharacters=
Date: Wed, 22 Apr 2015 14:18:50 +0000
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: exchange.contoso.com
X-MS-Has-Attach:
X-Auto-Response-Suppress: All
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Inbox-Rules-Loop: HR.Office@contoso.com
X-MS-TNEF-Correlator: GUIDLookingThing
x-originating-ip: [192.168.15.254]
MIME-Version: 1.0
Message-Id: <longrandomhexnumber@exchange.contoso.com>
This header provided me the key, but I didn't know it yet:
X-MS-Exchange-Inbox-Rules-Loop: HR.Office@contoso.com
That is the mailbox that has the hidden mailbox rule on it that needed to be deleted to stop the mail from going to the "random" people. (Quick note: I called Microsoft support and talked to someone in a foreign country. He had a very difficult time figuring out what the issue even was. I spent 45 minutes on the phone trying to explain to him what was happening and when it was quitting time for me he still didn't sound like he could understand what was happening when we were going to pick up working on this the next day. The rant here is that Microsoft support does not appear to employ people familiar with the nuts and bolts of the products they are supposed to support. I really don't care where in the world they are. I care that they seem lost when I am trying to explain what the problem is.)
When I get out of the shower the next morning I am convinced that the heart of the problem are those pesky hidden mailbox rules. I go back to work and start digging using MFCMAPI. What I find is that I need to delete that hidden rule on the HR.Office mailbox. Run it on your local desktop.
Open MFCMAPI:
Logon:
Select Outlook Profile:
Double click the HR.Office mailbox:
A new window will open. Expand Root Container -> Top of Information Store -> Inbox:
(If Top of Information Store is not there and you have IPM Subtree then your local Outlook in in cached mode. You need to change this. If you don't know what I'm talking about then you should stop what you're doing and not do anything else.)
Right click Inbox -> Other tables -> Rules table:
Find the hidden mailbox rule:
Delete the hidden mailbox rule:
That pretty much solved the problem that I had. Of course I don't know yet if there are other problems that this caused. I don't believe so. If you're Exchange Admin I am sure you are fully aware to be afraid of doing some of this stuff. Of course I also remember that at the last job this same problem cropped up and no one knew how to solve it.
Thursday, March 14, 2013
Exchange 2010 WinRM error
I upgraded my Exchange boxes from Exchange 2010 SP1 to Exchange 2010 SP3 last night. On the last mailbox server in the DAG I was unable to open the EMC or EMS. I don't have the exact error but this is mostly what the EMS was throwing:
"The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid."
The EMC was giving a kerberos error. I couldn't copy and paste it into anything and could only click retry, so I don't have the error because I didn't write it down.
After reinstalling the WinRM IIS thing about 10 times and running quickconfig (qc, not all typed out) and going through every single setting in IIS and comparing the broken DAG machine with the working DAG machine I was stuck. (And I'm sure you know exactly what I'm talking about because it's always the same answers to the same thing that never works but you try it 3 or 4 times because you don't know what else to do but you have to do something so...)
This blog pointed me in the right direction:
http://trikks.wordpress.com/2012/08/13/exchange-error-of-death-the-winrm-client-cannot-process-the-request-it-cannot-determine-the-content-type-of-the-http-response-from-the-destination-computer/
As it turns out the following file had errors in it:
E:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell\web.config
On the server that was broken there were multiple entries with a path like the following:
On my good server it had the same line as:
I renamed the broken web.config file and copied over the working one from my other box and everything just worked from that point.
This tool was no help to me on this error (probably because Exchange powershell was broken?):
http://blogs.technet.com/b/exchange/archive/2010/12/07/3411644.aspx
I hope this helps someone.
{edit - corrected typo in a sentence}
"The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid."
The EMC was giving a kerberos error. I couldn't copy and paste it into anything and could only click retry, so I don't have the error because I didn't write it down.
After reinstalling the WinRM IIS thing about 10 times and running quickconfig (qc, not all typed out) and going through every single setting in IIS and comparing the broken DAG machine with the working DAG machine I was stuck. (And I'm sure you know exactly what I'm talking about because it's always the same answers to the same thing that never works but you try it 3 or 4 times because you don't know what else to do but you have to do something so...)
This blog pointed me in the right direction:
http://trikks.wordpress.com/2012/08/13/exchange-error-of-death-the-winrm-client-cannot-process-the-request-it-cannot-determine-the-content-type-of-the-http-response-from-the-destination-computer/
As it turns out the following file had errors in it:
E:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell\web.config
On the server that was broken there were multiple entries with a path like the following:
<codebase href="file:///%ExchangeInstallDir%bin\Microsoft.Exchange.Configuration.RedirectionModule.dll" version="14.0.0.0">
On my good server it had the same line as:
<codebase href="file:///E:\Program Files\Microsoft\Exchange Server\V14\bin\Microsoft.Exchange.Configuration.RedirectionModule.dll" version="14.0.0.0">
I renamed the broken web.config file and copied over the working one from my other box and everything just worked from that point.
This tool was no help to me on this error (probably because Exchange powershell was broken?):
http://blogs.technet.com/b/exchange/archive/2010/12/07/3411644.aspx
I hope this helps someone.
{edit - corrected typo in a sentence}
Friday, September 18, 2009
It's been a while...
It's been a long time since I've posted on here. We have our deployment working and it's been stable for about a year and a half now I guess. The new MDT 2010 is out now. I never looked at any of the betas for it because I did not want to disturb my current deployment point. I recently downloaded the 2010 (RTM?) and looked at it and it is going to take me a little bit to digest it.
The first thing that I can say about it is that I cannot wait to play with it. The MS folks have added quite a bit of nice features it looks like to me. I wasn't bright enough to understand how to setup one deployment point and have it be a master for some other ones (for lack of a better term). It appears that is easy in 2010 (and was supposedly in earlier ones, but not easy). Following that same way of doing things having a dev and prod deployment looks to be tons easier now too.
There are lots of improvements so if you haven't looked at MDT 2010 you really should take a peek. As I get to start working with it over the next little bit I will get back to updating this blog with the things that I figure out.
The first thing that I can say about it is that I cannot wait to play with it. The MS folks have added quite a bit of nice features it looks like to me. I wasn't bright enough to understand how to setup one deployment point and have it be a master for some other ones (for lack of a better term). It appears that is easy in 2010 (and was supposedly in earlier ones, but not easy). Following that same way of doing things having a dev and prod deployment looks to be tons easier now too.
There are lots of improvements so if you haven't looked at MDT 2010 you really should take a peek. As I get to start working with it over the next little bit I will get back to updating this blog with the things that I figure out.
Wednesday, May 28, 2008
Production Deployment
We started our production deployment here on May 12, and all in all I am pretty happy. There have been a couple "gotchas", but after about a year of working on this thing I have to say it has went very smoothly. One of our biggest issues here is bandwidth. Going from XP to Vista our deployment has, in most instances, trippled in size. With XP we were about 10G in size, and with Vista we are at about 30G. The problem with that is that our network infrastructure is inconsistent at best. There is nothing I can do about that and so that's the limitation that I have to deal with.
The first deployment that we did we did on an 8-port (that's what we had at the time) Gbit switch. That allowed us to do six machines at a time. Two ports were used by the net connection for windows updates and the nas for building from. Those six machines took three hours. Next we put twelve machines on a 100Mb switch. Those machines took four and a half hours. That evening we plugged the nas into the wall and started the rest of our machines (about 25). Sorry I don't have exact figures on this, but by the next morning several machines failed asking for the CD, I think 3 just failed with some deployment error, and 4-6 were still building.
So after looking at this I tried to think of different things to try to get things done faster. First off, I have to say that I am pretty happy with the loading on our nas. I don't know how well it should load, but I know that we were never able to load our old server pulling down ghost images like we are able to do on the nas (If we got more than 5 or 6 ghost sessions going some would start to fail). We are using a Qnap TS-409 Pro nas. One of the things that I thought about doing is copying the application install files down to the local machine and then have the task sequence fire them off the local hdd. Currently the installs are fired off the server/nas. I don't know if that would work in our environment because until the past year we always got the smallest hdd we could from the vendor because we did not really need any bigger drives. I also thought about other temporary network topologies, but nothing really stands out as a solution. So in the end we just opted for a 24-port Gbit switch and let em grind.
The biggest time hog for deployment/installing is Visual Studio 2008. The old version took forever to install. I think this one takes twice as long to install! This install just drives me insane. I have sat and watched the resource monitor for this install and it is just slow. First off the it looks like msiexec.exe needs to be ported over to being a multithreaded app. For most all of the VS install the processor is pegged right at 50%. (I've tried looking to see if there is any documentation on Windows Installer being either single threaded or multithreaded and I could not find anything, so I am assuming it is single threaded.) Office 2007 and CS3 take some time too, but they seem to be a fair amount better about dealing with network/cpu/hdd/memory usage for their installs. VS just seems to have a one track mind though. It is either using network or cpu or hdd, but when one spikes all the others fall off.
As for any errors that I've seen the most common one is a program give me an exit code of 13 and I cannot find a way for the deployment wizzard to accept that return code as ok. Other machines have failed up doing windows updates, which to me is not a show stopper. They will get their updates soon enough. One or two errors happened that caused us to just wipe the drive and start over. I don't remember the exact errors, but they were pretty odd ones about installing Vista and wiping the hdd did the trick.
The first deployment that we did we did on an 8-port (that's what we had at the time) Gbit switch. That allowed us to do six machines at a time. Two ports were used by the net connection for windows updates and the nas for building from. Those six machines took three hours. Next we put twelve machines on a 100Mb switch. Those machines took four and a half hours. That evening we plugged the nas into the wall and started the rest of our machines (about 25). Sorry I don't have exact figures on this, but by the next morning several machines failed asking for the CD, I think 3 just failed with some deployment error, and 4-6 were still building.
So after looking at this I tried to think of different things to try to get things done faster. First off, I have to say that I am pretty happy with the loading on our nas. I don't know how well it should load, but I know that we were never able to load our old server pulling down ghost images like we are able to do on the nas (If we got more than 5 or 6 ghost sessions going some would start to fail). We are using a Qnap TS-409 Pro nas. One of the things that I thought about doing is copying the application install files down to the local machine and then have the task sequence fire them off the local hdd. Currently the installs are fired off the server/nas. I don't know if that would work in our environment because until the past year we always got the smallest hdd we could from the vendor because we did not really need any bigger drives. I also thought about other temporary network topologies, but nothing really stands out as a solution. So in the end we just opted for a 24-port Gbit switch and let em grind.
The biggest time hog for deployment/installing is Visual Studio 2008. The old version took forever to install. I think this one takes twice as long to install! This install just drives me insane. I have sat and watched the resource monitor for this install and it is just slow. First off the it looks like msiexec.exe needs to be ported over to being a multithreaded app. For most all of the VS install the processor is pegged right at 50%. (I've tried looking to see if there is any documentation on Windows Installer being either single threaded or multithreaded and I could not find anything, so I am assuming it is single threaded.) Office 2007 and CS3 take some time too, but they seem to be a fair amount better about dealing with network/cpu/hdd/memory usage for their installs. VS just seems to have a one track mind though. It is either using network or cpu or hdd, but when one spikes all the others fall off.
As for any errors that I've seen the most common one is a program give me an exit code of 13 and I cannot find a way for the deployment wizzard to accept that return code as ok. Other machines have failed up doing windows updates, which to me is not a show stopper. They will get their updates soon enough. One or two errors happened that caused us to just wipe the drive and start over. I don't remember the exact errors, but they were pretty odd ones about installing Vista and wiping the hdd did the trick.
Thursday, May 8, 2008
Quick and dirty "spare" deployment point
In our environment we have some "problem" labs that we have to deploy Vista into. For one reason or another the network will not really handle deploying several machines at a time. Trying to remedy this solution I got us a nas to work off of. This presents some interesting challenges.
The deployment tool isn't really setup to handle a dual server type setup very well (if at all). I might be missing something that would make this really easy, but I don't think so. Other blogs I have read talk about dns round-robbin and load balancing and the like, but none of those scenarios really address the problems that I face -- slow connections to the server room, either because of a wan-link or a flakey network. At any rate I got us a small nas so that I would have a local resource we could build from in any lab.
What I did was create shares on the nas that are named the same as the ones that are on our primary server. I use two different shares for the deployment and the applications. I then copied all the files over from each share to the corresponding one I made on the nas. After doing this I had to modify a few things to point to the nas.
One of the first things that I had to modify was the bootstrap.ini file to point to my nas -- but that was easier said than done. There might be an easier way to do it than what I put here, but this is what I did. I took the LTI iso and mounted it so I could read/write to it. I then had to open the boot.wim in the Sources folder that is in the iso (for the time being I'm going to leave it to your google-foo to figure that out -- if anyone asks I'll write that up later). I edited the bootstrap.ini in there and saved all of it back out and burned a boot cd.
From there I had to modify serveral files on the nas to point to the nas:
\Control\Applications.xml
and
\Control\*\TS.xml
* is the task sequence number of any task sequence you might use from the nas
I did all of this outside of the deployment tool because I did not want to make two deployment points and I didn't want to duplicate task sequences and have to edit both of them for each change I make (well I have to edit it anyway, but I would rather use a txt editor to do a search and replace rather than using the task sequence GUI).
That's my quick and dirty way to use another server to deploy from. Good luck.
The deployment tool isn't really setup to handle a dual server type setup very well (if at all). I might be missing something that would make this really easy, but I don't think so. Other blogs I have read talk about dns round-robbin and load balancing and the like, but none of those scenarios really address the problems that I face -- slow connections to the server room, either because of a wan-link or a flakey network. At any rate I got us a small nas so that I would have a local resource we could build from in any lab.
What I did was create shares on the nas that are named the same as the ones that are on our primary server. I use two different shares for the deployment and the applications. I then copied all the files over from each share to the corresponding one I made on the nas. After doing this I had to modify a few things to point to the nas.
One of the first things that I had to modify was the bootstrap.ini file to point to my nas -- but that was easier said than done. There might be an easier way to do it than what I put here, but this is what I did. I took the LTI iso and mounted it so I could read/write to it. I then had to open the boot.wim in the Sources folder that is in the iso (for the time being I'm going to leave it to your google-foo to figure that out -- if anyone asks I'll write that up later). I edited the bootstrap.ini in there and saved all of it back out and burned a boot cd.
From there I had to modify serveral files on the nas to point to the nas:
\Control\Applications.xml
and
\Control\*\TS.xml
* is the task sequence number of any task sequence you might use from the nas
I did all of this outside of the deployment tool because I did not want to make two deployment points and I didn't want to duplicate task sequences and have to edit both of them for each change I make (well I have to edit it anyway, but I would rather use a txt editor to do a search and replace rather than using the task sequence GUI).
That's my quick and dirty way to use another server to deploy from. Good luck.
Friday, April 25, 2008
Using Robocopy
In part of my deployment I use robocopy to copy over a batch file for later use by the system. I am now to the point in my deployment where I am working on the "little" things and getting the kinks out of them. After my task sequence ran robocopy it would fail because robocopy returned an exit code of 1. After doing a bit of digging I found that means everything worked out just fine. So if you are using robocopy in any of your task sequences you will want to find that/those step(s) and go to the options tab and edit a few things. I put a check in front of "Continue on error" so that copying over one file is not going to derail my deployment. I also added in a 1 in the "Success codes:" box. I have not ever touched this box before, but I have faith that is going to solve my problem with robocopy. Be aware that you may have to put other robocopy "success" codes in to make your particular deployment not bark at you.
Friday, March 28, 2008
Booting off USB
Found a little note in the MSDT help files on booting off USB. I had a couple little gotchas when doing this, and I'll let you know what they are. One of the gotchas is in their instructions so I'll give you my instructions (this wipes your flash drive, just so you know).
1 Open admin cmd prompt.
2 Run "diskpart".
3 Run diskpart command "list disk".
4 Make note of the disk number your flash drive is.
5 Run diskpart command "select disk (drive number)".
6 Run diskpart command "clean".
7 Run diskpart command "create partition primary".
8 Run diskpart command "select partition 1".
9 Run diskpart command "active".
10 Run diskpart command "format fs=fat32".
11 Run diskpart command "assign"
12 Run diskpart command "exit"
Then the instructions tell you to use xcopy to copy the contents of your boot CD to the flash drive. Xcopy would not work for me. I just copied the contents of the CD over to the flash drive and it seems to work just fine.
Remember to disconnect your flash drive before your machine needs to reboot or your sequence will fail.
1 Open admin cmd prompt.
2 Run "diskpart".
3 Run diskpart command "list disk".
4 Make note of the disk number your flash drive is.
5 Run diskpart command "select disk (drive number)".
6 Run diskpart command "clean".
7 Run diskpart command "create partition primary".
8 Run diskpart command "select partition 1".
9 Run diskpart command "active".
10 Run diskpart command "format fs=fat32".
11 Run diskpart command "assign"
12 Run diskpart command "exit"
Then the instructions tell you to use xcopy to copy the contents of your boot CD to the flash drive. Xcopy would not work for me. I just copied the contents of the CD over to the flash drive and it seems to work just fine.
Remember to disconnect your flash drive before your machine needs to reboot or your sequence will fail.
Custom script move OU failing with 0x8007052E error.
After upgrading and messing around with some new hardware (looking at a NAS for a mobile build server) I started getting errors with the custom OU moving scripts that I have been using for a while. I copied my deployment point over to the NAS I'm looking at and made the changes needed in the bootstrap.ini and applications.xml files. I tried my deployment off the NAS and when it got to the Z-MoveComputer_StagingOU.wsf script it failed with an error code of 0x8007052E (-2 something dec -- sorry didn't write it down). After doing a fair amount of trouble shooting I found out that off the NAS it did not like the following line in the code (probably 2/3 of the way down):
Set objContainer= openDS.OpenDSObject("LDAP://" & strDC & "/" & strStagingOU, strAccounttoJoinWith & "@" & strDomain, strAccountPassword, ADS_SECURE_AUTHENTICATION)
In particular I had to make admin@domain into doman\admin in order for the script to function. If you are seeing this error then see if swapping that helps you. The NAS is not on the domain and our other deployment server is. I don't know why this would need to change on one vs. the other, but I don't make the rules, I just play the game.
Set objContainer= openDS.OpenDSObject("LDAP://" & strDC & "/" & strStagingOU, strAccounttoJoinWith & "@" & strDomain, strAccountPassword, ADS_SECURE_AUTHENTICATION)
In particular I had to make admin@domain into doman\admin in order for the script to function. If you are seeing this error then see if swapping that helps you. The NAS is not on the domain and our other deployment server is. I don't know why this would need to change on one vs. the other, but I don't make the rules, I just play the game.
Thursday, February 28, 2008
Custom script for automating app install by machine name.
Phew what a title! Ok so it took me about a week to get this little script functioning. The reason that I came up with this script is that I really could not find a way to have automated application installs by machine name that fit into our "ecosystem". The old way we did application installs in XP and before was by a vbscript. I'm not opposed to the old way, but the old way that we did it had no error checking. What I really wanted to do was come up with something that would tell me what application failed to install if one or more did fail. Since this is already handled in MSDT I really wanted to leverage that.
I don't claim to be a programmer. I'm a hardware guy. I'm sure that someone could come up with more eloquent ways of putting this script together (and if you do please let me know), but what I have works for me. In our environment we have labs that need a basic set of software installed and then they have different sets depending on what lab that is. We have tried as best as we can to standardize our machine names, and that helps a lot. Thus, one of the things this script does is strip out the lab name from the machine name (ie BB100-01 is lab BB100 machine number 01).
The script then looks at a file I've called sourcetxt.txt to see what software needs to get installed where. Because of my ability with scripting everything has to be jumbled up together making it hard to read, but if the data is not in the correct format then the script dies. The data in this file takes the form of:
LabID=All:AppID=keyaccess
LabID can be either All or the name of the lab (BB100 from above). The : is the field delimiter. The AppID is the "name" of the application to be installed. I say it like that because the name is actually a file with that exact name + .txt that has the GUID in it for the application. It can have multiple GUIDs in it. I did this because we key our apps and thus I have the actual app install and then I have the keyed exe to install over it (If I ever get the time to devote to learning key server I could learn to deputize installers, but that's a whole other topic right there).
Included with the zip file are three files: \Z-CUSTOM_LabApps.wsf, \Applications\sourcetxt.txt, and \Applications\winscp.txt
I put my script in the scripts folder and I made a subdir called Applications in that folder to house the two files that references.
After the script strips the lab name out, reads the apps required in the lab and then gets the associated GUIDs of those apps it then writes those values back into the VARIABLES.DAT file. This then allows the MSDT framework to handle the app install and report back any app install errors. If you have applications specified in your CustomSettings.ini file then you will have to modify the script to start with the number that you left off with.
I created my own custom task sequence to run this script. I run it during the Preinstall\New Computer Only section after the "Copy scripts" built-in task runs.
Hope it helps!
Download the LabApps.zip here.
I don't claim to be a programmer. I'm a hardware guy. I'm sure that someone could come up with more eloquent ways of putting this script together (and if you do please let me know), but what I have works for me. In our environment we have labs that need a basic set of software installed and then they have different sets depending on what lab that is. We have tried as best as we can to standardize our machine names, and that helps a lot. Thus, one of the things this script does is strip out the lab name from the machine name (ie BB100-01 is lab BB100 machine number 01).
The script then looks at a file I've called sourcetxt.txt to see what software needs to get installed where. Because of my ability with scripting everything has to be jumbled up together making it hard to read, but if the data is not in the correct format then the script dies. The data in this file takes the form of:
LabID=All:AppID=keyaccess
LabID can be either All or the name of the lab (BB100 from above). The : is the field delimiter. The AppID is the "name" of the application to be installed. I say it like that because the name is actually a file with that exact name + .txt that has the GUID in it for the application. It can have multiple GUIDs in it. I did this because we key our apps and thus I have the actual app install and then I have the keyed exe to install over it (If I ever get the time to devote to learning key server I could learn to deputize installers, but that's a whole other topic right there).
Included with the zip file are three files: \Z-CUSTOM_LabApps.wsf, \Applications\sourcetxt.txt, and \Applications\winscp.txt
I put my script in the scripts folder and I made a subdir called Applications in that folder to house the two files that references.
After the script strips the lab name out, reads the apps required in the lab and then gets the associated GUIDs of those apps it then writes those values back into the VARIABLES.DAT file. This then allows the MSDT framework to handle the app install and report back any app install errors. If you have applications specified in your CustomSettings.ini file then you will have to modify the script to start with the number that you left off with.
I created my own custom task sequence to run this script. I run it during the Preinstall\New Computer Only section after the "Copy scripts" built-in task runs.
Hope it helps!
Download the LabApps.zip here.
Friday, February 22, 2008
Sidebar crashing when installing applications
For whatever reason the sidebar seems to like to crash in the middle of application installations. It does not seem to matter what applications (but CS3 seems to be the worst one) I pick to install it seems to die along the way. It's kinda scary seeing those pop-up boxes coming up asking if you want to debug. So I added the following task sequence to kill the sidebar right before installing apps.
taskkill /F /IM sidebar.exe /T
Subscribe to:
Posts (Atom)