Exchange 2010 does not support the ESE API for doing backups like it did in 2003 and 2007 according to MSDN. I Quote: "Exchange 2010 no longer supports the ESE streaming APIs for backup and restore of program files or data. Instead, Exchange 2010 supports only VSS-based backups."
So my question is, if this is the case, why is the DLL (ESEBCLI2.DLL) still shipped with exchange 2010? I found it under C:\Program Files\Microsoft\Exchange Server\V14\Bin. Am I missing something here?
The High Availability component of Exchange 2010 uses some parts of the streaming backup API under the covers - for doing reseeds for example. The full API isn't supported though.
Related
I need to somehow move an Exchange 2016 Mailbox.edb to a new Exchange 2019 server. Is this possible without third party migration tools?
Doing an in-place migration apparently is not possible. Our cloud email company originally said they would do an in-place upgrade for us but then reneged. I also highly doubt they will allow us to connect our new server to theirs via a VPN. So I am left with somehow moving the files.
I haven't tried it, but I can't imagine Exchange Server 2019 will be able to mount a 2016 EDB mail store.
I have thoroughly searched online but I can only find info on in-place upgrades. I really hope I won't have to copy all the mailboxes to Outlook PST files and then push them back to the new server.
Thanks in advance for any help you can give me.
We are currently running a simplistic installation of BizTalk 2010 for some EDI mapping. I'd like to migrate these applications to BizTalk 2020. I'm not concerned about keeping the history of previous transactions.
Is it as simple as setting up a new BizTalk 2020 installation and importing the applications\Parties to 2020, or do they need to make a hop through another version (ie 2016)?
If you mean just to export the MSI and parties and then re-import them into BizTalk 2020, then the answer is probably no.
If you mean to open each solution in Visual Studio 2019 and upgrade them, recompile and deploy, and then test for issues, then yes, that is achievable.
Note: Going from BizTalk 2010 to a higher version there is a known issue with maps where the later versions use XslCompiledTransform class instead of XslTransform. See Known issues in BizTalk Server 2013. I also wrote a blog about it BizTalk 2013 R2 CU2 & BizTalk 2016 – Use XSL Transform and why you should fix the maps, rather than try and default it back to XslTransform.
EDI might have problems, because sometime parties cannot be directly migrated. In which case you will need to use the BizTalk Server Party Migration Tool which usually is included.
Also the SQL adapter has been removed in BizTalk 2020 (see Deprecated & Removed List), so if you have any ports using that you will need to replace it with WCF-SQL
Currently we are using plugins to integrate records for Dynamics CRM 2011 (on premise) to back office (SQL Server) using WCF as a bridge. This process is same for insert and update. (Plugin > WCF > stored procedure)
However, we are due to upgrade to Dynamics CRM 365 on Azure and wondering if there are any better (new tech!) ways to do the same process?
I would really appreciate if you can share your experience with similar CRM to Back Office sync.
We are using (and I recommend) Data Export service
Data Export is an add-on service made available as a Microsoft Dynamics 365 (online) solution that adds the ability to replicate Dynamics 365 (online) data to a Microsoft Azure SQL Database store in a customer-owned Microsoft Azure subscription. The supported target destinations are Microsoft Azure SQL Database and Microsoft Azure SQL Server on Microsoft Azure virtual machines. Data Export intelligently synchronizes the entire Dynamics 365 schema and data initially and thereafter synchronizes on a continuous basis as changes occur (delta changes) in the Microsoft Dynamics 365 (online) system.
Probably the easiest/cleanest way. Just a Managed solution import, enabling Change tracking for Entities, setup Azure SQL & Key vault, friendly Profile setup & sync issues troubleshooting.
If your WCF services is available in the internet I do not see any reason to change the working integration (unless you really want to get rid of good, old WCF :)).
If it is intranet-only app you will probably need to use some other integration patterns and technologies. For example: service bus, web jobs, app logic, etc.
All of them may work perfecly well, however there are many different conditions that need to be considered during decission process.
We've been asked to look at SharePoint 2010 Standard (we currently have a small intranet on SP2007) with an aim to building a number of custom workflow solutions.
I don't have much experience of SP2010, but from a period of learning/testing it seems to be a very cumbersome system more tailored to allowing individuals/teams to create their own web sites for a specific purpose?
I have also seen some blogs on WF4 - which I have even less experience of! Can WF4 be used "stand alone" or does it require SP2010?
The workflows will range from very basic to reasonably complex based upon variables. e.g. "Route to next person in chain", "route to team based on a value(s)".
So my question is: Could someone give me any assistance in deciding which route to attempt for building workflows? I'm not even sure of the questions to ask of each of them! I appreciate this is subjective, but I'm sure there are people out there who have experience of both?
My experience is in C#.Net/MVC and WCF - the overhead of simply getting an SP2010 Dev environment setup and configured has already made me wary of SP2010!
I can´t tell you much about SharePoint other than that SharePoint 2010 still uses WF3 for its workflow engine. In SP2013 they upgraded to WF4 so if you are looking to run WF4 style workflows you will need to use that instead.
Windows Workflow Foundation is independent of SharePoint. You can create your own Workflow host and Persistence layer. APress had a great book, Foundations of WF which served as a great introduction to Workflow in .net 3.5.
SharePoint 2010 is based on .net 3.5 SP1 and uses the old/original Workflow Engine. It implements its own host and persistence, so it's quite its own beast. There is a wealth of information available for Workflow in SP2007 and SP2010, which is good because the list of caveats, exceptions and "You need to know this, or it'll bite you" cases. In addition, SharePoint 2010 allows workflows to be created in multiple ways: Through Visual Studio (Like a "real" WF Project), through SharePoint Designer and through Visio (the latter two being limited).
WF4 is a new Workflow Engine that Microsoft introduced in .net 4.0. It is not supported in SharePoint 2010, but the next version - SharePoint 2013 - is based on .net 4.5 and should in theory offer support for WF4. I have not verified this though.
I am setting up SharePoint 2010 on one machine with SQL Server on a separate box to server as both the data store and serve reporting services (through SSRS/SP Integration).
In the past, I would install the WSS 3.0 for SharePoint 2007 on the SQL Server Box. It appears that there is no existing option for SP 2010. Am I missing something? Thanks.
It is possible, I believe you can specify a Database server when you are configuring the product.
This is probably a good start: http://technet.microsoft.com/en-us/library/ee667264.aspx
There are a number of "buried" articles ( for some reason I couldn't google them) in the Microsoft Sharpoint Documentation Tree:
(since I could not pust multiple links youre stick with this one)
Configuring on Multiple servers - my specific case